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ABSTRACT 


The  U.S.  Navy  is  developing  through-water  acoustic  communications  capability 
for  undersea,  distributed  systems.  These  wireless  communication  links  form  a  wide-area 
network  of  fixed  nodes  consistent  with  future  autonomous  sensors  on  the  seafloor. 
Mobile  nodes  may  operate  in  the  domain  of  the  grid  using  the  fixed  nodes  as  both 
navigation  reference  points  and  communication  access  points.  This  thesis  evaluates  the 
experimental  performance  of  such  networked  communications  between  an  undersea 
vehicle  and  a  ship.  Physical-layer  considerations  include  refraction,  wind-induced 
ambient  noise,  and  vehicle  aspect  angle. 
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The  ATM-885  telesonar  modem  is  designed  for  use  at  depths  up  to  2000 
meters.  It  is  a  self-contained,  internally  or  externally  powered  modem  with 
an  integral  transducer.  It  is  capable  of  transmission  rates  from  150  bps  to 
15360  bps  and  can  receive  at  rates  from  150  bps  to  2400  bps.  It  utilizes 
MFSK  modulation.  Channel-tolerance  features  include  data  redundancy, 

'A-rate  convolutional  coding,  and  multipath  guard  period  selection  [2] . 3 

This  originally  proposed  Seaweb  network  was  a  wide-area  grid.  The  4 
racom  buoys  on  the  deepest  contour  would  provide  links  to  surface  vessels 
in  the  deeper  water,  while  the  fifth  racom  provided  a  shore  connection. 
Depending  on  mission  requirements,  Seaweb  is  able  to  flex  and  scale  into 
any  architecture  provided  enough  nodes  are  available  to  support  the 

acoustics  of  the  through- water  communications  medium  [2] . 4 

The  planned  Seaweb  operational  network  charted  in  the  left  figure  consists 
of  telesonar  repeater  nodes  and  racom  buoys  displayed  on  the  right.  The 
grid  in  its  entirety  would  have  been  deployed  and  tested  prior  to 
commencing  the  exercise  had  weather  permitted  [2],  Nodes  indicated  in 
the  lower  left  comer  of  the  chart  were  to  be  reserved  as  spares  for  use 
during  an  intended  3-day  checkout  of  the  grid.  Because  of  foul  weather, 
the  3  days  of  checkout  were  lost,  and  all  spares  were  deployed  as  seen  in 

later  chapters . 5 

The  telesonar  repeater  nodes  were  deployed  from  the  deck  of  the  second 
ship.  It  is  possible  to  rig  them  to  be  deployed  off  of  a  small  RHIB,  rigid- 
hull  inflatable  boat.  The  deployed  assembly  rises  just  5  meters  above  the 
seafloor  and  is  then  recovered  by  remotely  commanding  the  acoustic 
release.  The  modem  itself  is  suspended  roughly  3  meters  above  the 
seafloor.  The  bum  wire  within  the  release  corrodes  and  within  five 
minutes,  the  attachment  separates  from  the  expendable  weight  and  the 
node  floats  to  the  sea  surface  to  be  recovered  by  a  RHIB.  The  telesonar 
modems  operate  at  acoustic  frequencies  9-14  kHz.  The  acoustic  release 

transmissions  occur  at  33  kHz  [2] . 6 

The  Seaweb  2004  racom  buoy  is  a  low-drag  small-cross-section  buoy 
tailored  for  survivability  in  strong  ocean  currents.  The  solar  panel  provides 
energy  during  daylight  in  order  to  conserve  battery  energy.  A 
microprocessor  processes  onboard  sensor  and  GPS  inputs  and  controls  and 
buffers  connections  between  the  telesonar,  Iridium,  and  FreeWave 
modems.  The  transducer  is  situated  approximately  50  meters  down  the 
mooring  cable  to  maximize  use  of  the  downward  refracting  channel 

characteristics  [3] . 7 

The  wind  speed  and  wave  height  were  measured  on  a  daily  basis.  These 
phenomena  largely  determined  the  ambient  noise  level  within  the 
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communications  channel.  Improved  Seaweb  performance  as  the 

experiment  progressed  is  partly  attributed  to  decreasing  noise  levels  [2] . 13 

Figure  7.  Weather  conditions  greatly  impact  Seaweb  performance.  The  9-14  kHz 
band  is  impaired  by  ambient  noise  from  wind-dependent  noise,  as  shown 
by  historically  derived  noise  spectra  [12] . 13 


Figure  8.  Historical  sound-speed  profile  for  the  experiment  site  indicates  a  50-meter 
deep  surface  mixed  layer  overlying  a  strong  thermocline  [6].  These  are 
typical  characteristics  of  continental  shelf  ocean  waters  in  temperate 
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223  rays  with  launch  angles  between  0°  and  -1 1.1°  are  numerically  traced 
through  a  25  5 -m  deep  stratified  medium  modeled  after  the  historical 

sound-speed  profile  of  Figure  8.  [6] . 15 
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with  Figure  9.  [6] . 18 

Figure  13.  Seaweb  underwater  network  is  an  implementation  of  the  physical,  link  and 
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Seaweb  clients . 19 

Figure  14.  Seaweb  link-layer  handshake  protocol  for  data  transfer  involves  Node  A 
initiating  a  request-to-send  (RTS)  utility  packet.  So  addressed,  Node  B 
awakens  and  demodulates  the  RTS.  Node  B  responds  to  A  with  a  clear-to- 
send  (CTS)  utility  packet  [2,  8] . 21 


Figure  15.  Selective  automatic  repeat  request  (SRQ)  is  a  link-layer  mechanism  for 
reliable  transport  of  large  data  files  between  neighboring  nodes  even  when 
the  physical  layer  suffers  high  bit-error  rate.  Purple  arrows  depict  Seaweb 
utility  packets  including  RTS,  CTS,  MAC  header  (HDR),  and  SRQ.  Red 

arrows  are  Data  subpackets  [2,  8] . 22 

Figure  16.  The  initial  deployed  Seaweb  operational  grid  included  2  racom  gateway 
buoys  and  39  telesonar  repeater  nodes.  The  gateway  buoys  are  equipped 
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[2] . 24 

Figure  17.  The  communications  protocol  was  such  that  the  undersea  vehicle  would 
initiate  all  communications.  The  message  flows  through  the  grid, 
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The  Seaweb  network  layer  routes  the  data  packet  through  the  grid  based 
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I. 


INTRODUCTION 


This  thesis  examines  the  ability  of  an  undersea  vehicle  to  communicate  through  a 
distributed  grid  deployed  on  the  ocean  floor.  Half-duplex  acoustic  links  and  long 
latencies  due  to  the  speed  of  sound  through  water  are  only  some  of  the  challenges 
encountered  when  implementing  such  mobile  connectivity.  In  2004,  a  U.S.  Navy  Seaweb 
experiment  installed  a  Seaweb  grid  and  achieved  networked  bidirectional 
communications  with  an  underwater  vehicle.  This  introductory  chapter  gives  a  brief 
description  of  the  underwater  wireless  network  and  the  fixed  and  mobile  nodes  used  in 
the  Seaweb  2004  Experiment. 


A.  SEAWEB  UNDERWATER  WIRELESS  NETWORK 

The  Seaweb  network  is  intended  to  provide  command,  control,  communications 
and  navigation  for  autonomous  and  manned  nodes  such  as  fixed  sensors  and  instruments 
on  the  seabed,  undersea  vehicles,  and  surface  vehicles  operating  in  arbitrary  ocean 
environments  for  various  missions  [1],  Seaweb  is  a  distributed  grid  of  interoperable 
telesonar  (i.e.,  fe/ecommunications  .sound  navigation  ranging)  modems  capable  of 
supporting  networked  acoustic  communications  and  node-to-node  ranging.  To  be 
operationally  practical,  the  communication  system  needs  to  be  reliable,  energy  efficient, 
deployable,  interoperable,  flexible,  affordable,  and  secure.  The  Seaweb  grid  is  scaleable 
and  its  relatively  short  links  permit  physical-layer  communications  at  high  enough 
frequencies  to  support  useful  bandwidth,  small  transducers,  directivity,  deployable 
packaging,  low  battery  power,  and  inherent  transmission  security  (TRANSEC).  Seaweb’s 
architecture  is  consistent  with  the  Navy  mandate  for  distributed  off-board  sensors  and 
vehicles. 

B.  NETWORKING  WITH  UNDERSEA  VEHICLES 

Mobile  nodes  have  unique  issues  in  maintaining  connectivity  within  the  Seaweb 
grid.  Mobile  connectivity  is  hindered  by  many  factors  associated  with  the  telesonar 
physical  layer  such  as  the  half-duplex  links,  the  long  latencies  (speed  of  sound),  and  the 
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range  limitations  of  the  underwater  acoustic  channel.  While  transmission  loss  from 
geometric  spreading  only  depends  on  propagation  range,  absorption  loss  increases  with 
both  range  and  frequency,  thus  limiting  the  available  useful  spectral  bandwidth.  Channel 
behavior  is  similar  to  that  of  a  waveguide  but  shadow  zones  can  exist  in  the  environment 
because  of  refraction  and  boundary  effects.  In  addition  to  these  detrimental  propagation 
factors,  the  channel  is  further  impaired  by  the  possibility  of  high  ocean  noise  levels  from 
wind,  shipping,  and  biologies. 

Nevertheless,  there  has  been  substantial  progress  in  the  ability  to  operate  manned 
and  unmanned  vehicles  at  depth  while  maintaining  communications  with  the  terrestrial 
world.  While  the  provision  for  cellular  addressing  was  incorporated  into  the  Seaweb  2004 
utility  packets,  the  ability  of  a  mobile  Seaweb  node  (e.g.  the  underwater  vehicle)  to 
automatically  maintain  network-layer  connectivity  has  not  been  fully  implemented.  This 
was  overcome  in  this  experiment  with  a  special-purpose  transport-layer  protocol 
requiring  the  undersea  vehicle  to  initiate  all  communications.  As  Seaweb  advances 
technologically,  the  ability  to  maintain  network-layer  connectivity  and  communications 
will  be  further  developed. 
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II.  SEAWEB  COMPONENTS 


Seaweb  2004  was  a  collaborative  experiment  involving  efforts  from  SSC  San 
Diego,  Johns  Hopkins  University,  Naval  Postgraduate  School,  and  numerous  other 
organizations.  The  Seaweb  grid  was  installed  along  the  outer  continental  shelf  and  was 
the  largest  deployed  to  date.  The  network  was  composed  of  40  repeater  nodes,  three 
gateway  buoys,  two  ships,  and  an  undersea  vehicle.  The  goal  of  Seaweb  2004  was 
bidirectional  communications  with  an  undersea  vehicle  operating  within  the  context  of 
the  Seaweb  grid.  This  chapter  describes  the  components  of  Seaweb  and  their  role  in 
supporting  the  Seaweb  2004  goal. 


Figure  1.  The  ATM-885  telesonar  modem  is  designed  for  use  at  depths  up  to  2000  meters. 

It  is  a  self-contained,  internally  or  externally  powered  modem  with  an  integral 
transducer.  It  is  capable  of  transmission  rates  from  150  bps  to  15360  bps  and  can 
receive  at  rates  from  150  bps  to  2400  bps.  It  utilizes  MFSK  modulation.  Channel- 
tolerance  features  include  data  redundancy,  A-rate  convolutional  coding,  and 
multipath  guard  period  selection  [2], 


All  Seaweb  2004  modems  were  Benthos  Inc.  ATM-885  telesonar  modems,  built 
around  the  printed  circuit  board  shown  in  Figure  1.  The  modems  were  upgraded  with 
Seaweb  Version  14.4  firmware  owned  and  developed  by  the  U.S.  Navy.  Version  14.4 
retains  all  previously  demonstrated  Seaweb  functions  as  discussed  in  Rice  [1],  with 
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several  upgrades.  These  upgrades  include  Doppler  processing  that  permits  node-to-node 
range  rates  in  excess  of  20  kts,  the  capacity  to  address  up  to  60  nodes,  a  refined 
Ping/Echo  ranging  function,  and  a  new  networked  diagnostic  command  that  remotely 
measures  and  reports  link  performance  between  arbitrarily  specified  node  pairs. 


B.  SEA  WEB  GRID 


Figure  2.  This  originally  proposed  Seaweb  network  was  a  wide-area  grid.  The  4  racom 
buoys  on  the  deepest  contour  would  provide  links  to  surface  vessels  in  the  deeper 
water,  while  the  fifth  racom  provided  a  shore  connection.  Depending  on  mission 
requirements,  Seaweb  is  able  to  flex  and  scale  into  any  architecture  provided 
enough  nodes  are  available  to  support  the  acoustics  of  the  through-water 
communications  medium  [2], 


Seaweb  topology  possibilities  are  limitless  due  to  the  ad  hoc  fashion  in  which 

nodes  can  be  deployed  and  networked  together.  Therefore,  dependent  upon  the  mission  at 

hand,  node  deployment  stations  are  chosen  to  provide  the  best  communications  coverage 

possible.  The  number  of  available  nodes,  weather  conditions,  and  the  ocean  environment 

dictate  the  area  of  communications  coverage  provided  by  Seaweb.  Historical  propagation 

predictions,  measured  sound  speed  profiles,  and  ray  trace  diagrams  are  used  to  specify 

the  nominal  node  ranges.  The  initially  proposed  Seaweb  2004  topology  was  a  grid 

structure,  as  charted  in  Figure  2.  As  experiment  planning  progressed,  the  grid  coverage 
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was  refined  as  depicted  in  Figure  3.  Also  shown  in  Figure  3  are  components  of  the 
Seaweb  2004  network  during  experiment  staging. 

To  mitigate  experiment  risk,  a  pilot  grid  was  deployed  and  tested  just  prior  to 
experiment  commencement.  The  performance  of  that  pilot  grid  and  analysis  of  telesonar 
channel  conditions  guided  the  final  design  of  the  operational  Seaweb  network.  Once  the 
full  grid  was  installed,  three  days  were  allocated  for  end-to-end  testing  that  would  have 
involved  a  second  ship  connecting  with  each  node  in  the  grid  for  connectivity  tests 
between  the  two  ships.  Unfortunately,  schedule  compression  due  to  adverse  weather 
precluded  the  possibility  of  these  3  days  of  end-to-end  testing. 


Figure  3.  The  planned  Seaweb  operational  network  charted  in  the  left  figure  consists  of 
telesonar  repeater  nodes  and  racom  buoys  displayed  on  the  right.  The  grid  in  its 
entirety  would  have  been  deployed  and  tested  prior  to  commencing  the  exercise 
had  weather  permitted  [2],  Nodes  indicated  in  the  lower  left  comer  of  the  chart 
were  to  be  reserved  as  spares  for  use  during  an  intended  3 -day  checkout  of  the 
grid.  Because  of  foul  weather,  the  3  days  of  checkout  were  lost,  and  all  spares 
were  deployed  as  seen  in  later  chapters. 


5 


C.  TELESONAR  REPEATER  NODES 

In  Seaweb  2004,  all  telesonar  repeater  nodes  were  hand-deployed  from  a  large 
ship  advancing  at  six  knots.  Figure  4  depicts  the  deployment,  rigging  and  posture  of  the 
repeater  node.  By  virtue  of  an  acoustic  release,  the  repeater  nodes  are  recoverable  for 
post-experiment  reuse,  for  mid-experiment  servicing,  or  for  mid-experiment 
redeployment  to  more  advantageous  locations.  The  acoustic  release  connects  the 
telesonar  modem  to  the  anchor  fixing  the  node  to  the  seafloor.  Deployment  latitudes  and 
longitudes  are  logged  to  aid  in  node  recovery  and  network  analysis. 


Subsurface  Float 
(24  pounds  positive) 


(14  pounds  negative) 


Telesonar  Modem 


Acoustic  Release 


Clump  Weight 
(60  pounds  negative) 


2m 


1m 


.5m 


1m 


.5m 


Figure  4.  The  telesonar  repeater  nodes  were  deployed  from  the  deck  of  the  second  ship.  It  is 
possible  to  rig  them  to  be  deployed  off  of  a  small  RHIB,  rigid-hull  inflatable  boat. 
The  deployed  assembly  rises  just  5  meters  above  the  seafloor  and  is  then 
recovered  by  remotely  commanding  the  acoustic  release.  The  modem  itself  is 
suspended  roughly  3  meters  above  the  seafloor.  The  bum  wire  within  the  release 
corrodes  and  within  five  minutes,  the  attachment  separates  from  the  expendable 
weight  and  the  node  floats  to  the  sea  surface  to  be  recovered  by  a  RHIB.  The 
telesonar  modems  operate  at  acoustic  frequencies  9-14  kHz.  The  acoustic  release 
transmissions  occur  at  33  kHz  [2], 
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The  stock  telesonar  modems  operate  in  water  depths  to  2000  m.  Alternative 
pressure  housings  permit  operation  to  10,000  m  depths.  The  acoustic  releases  procured 
for  Seaweb  2004  are  rated  only  to  300  meters  according  to  the  manufacturer.  However, 
during  this  experiment  the  repeater  nodes  were  deployed  in  waters  up  to  350  meters  deep 
without  failures. 


D.  RACOM  BUOYS 


a 


Figure  5.  The  Seaweb  2004  racom  buoy  is  a  low-drag  small-cross-section  buoy  tailored  for 
survivability  in  strong  ocean  currents.  The  solar  panel  provides  energy  during 
daylight  in  order  to  conserve  battery  energy.  A  microprocessor  processes  onboard 
sensor  and  GPS  inputs  and  controls  and  buffers  connections  between  the 
telesonar,  Iridium,  and  FreeWave  modems.  The  transducer  is  situated 
approximately  50  meters  down  the  mooring  cable  to  maximize  use  of  the 
downward  refracting  channel  characteristics  [3]. 


7 


Racom,  radio  acoustic  communication,  buoys  provide  the  gateway  link  between 
the  undersea  network  and  the  users.  The  racom  buoys  used  in  the  Seaweb  2004 
experiment  incorporate  FreeWave  radio  technology  as  well  as  Iridium  satellite 
communication  technology.  The  FreeWave  radio  provided  a  line-of-sight  radio  link 
between  the  racom  buoy  and  the  ship.  The  Iridium  satellite  communications  link  provides 
an  alternative  to  the  line-of-sight  FreeWave  link,  but  it  was  not  used  in  Seaweb  2004. 

The  new  low-drag  design  of  the  racom  buoy  is  well  suited  for  operating  in  strong 
ocean  currents.  A  numerical  drag  analysis  aided  in  optimizing  the  scope  of  the  mooring 
line  and  in  determining  the  anchor  requirements.  The  buoys  were  anchored  to  the  seafloor 
using  a  2.5:1  scope-to-depth  ratio  on  the  mooring  line.  Using  the  above  dimensions,  the 
220-meter  water  depth  at  the  designated  racom  mooring  station  produced  a  500-m  radius 
watch  circle  around  the  anchor  position  [3],  The  buoy  and  mooring  design  are  illustrated 
in  Figure  5. 

The  racom  buoys  were  deployed  from  the  stem  of  a  ship  while  underway  ahead 
slow  into  the  current.  The  racom  buoy  was  deployed  buoy  first,  with  slow  payout  of  the 
mooring  line  culminating  in  release  of  the  anchor  at  the  desired  mooring  coordinates. 
Because  of  the  severity  of  sea  state  and  currents  at  the  site,  the  racom  buoys  were 
expected  to  be  a  vulnerable  link  in  the  Seaweb  2004  network.  Two  racoms  were  deployed 
prior  to  beginning  the  experiment  and  an  additional  racom  was  deployed  on  the  fourth 
day  of  the  experiment  for  redundancy.  Three  additional  spares  were  on  deck  of  the 
second  ship.  [3] 


E.  SEAWEB  SERVER 

The  ship  and  undersea  vehicle  each  host  a  Seaweb  server.  The  Seaweb  server  on 
the  ship  was  designated  the  Seaweb  administrator  with  power  to  establish  Seaweb 
network-layer  routes  and  specify  Seaweb  link-layer  protocols.  The  network-layer  routes 
are  defined  by  neighbor  and  routing  tables  stored  on  the  distributed  modems.  These  tables 
may  be  remotely  modified  by  the  Seaweb  administrator.  The  Seaweb  administrator  may 
remotely  control  the  physical  layer  parameters  such  as  bit  rate,  coding  parameters,  and 
source  level  by  manipulating  register  settings  in  the  modems.  [4] 
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The  server  also  provides  the  interface  between  the  Seaweb  network  and  client 
applications.  The  Seaweb  server  connects  a  client  end-user  to  the  underwater  acoustic 
network  through  a  TCP/IP  socket  connection.  The  server  queues  client  outgoing  data  in  a 
message  database  table  and  archives  the  data  packet  in  the  modem  messages  table.  Then 
it  transmits  the  packet  to  the  acoustic  network  through  the  racom  gateway  buoy.  Many 
types  of  links  between  the  server  and  the  racom  gateway  buoy  have  been  previously 
demonstrated.  These  links  include  FreeWave  line-of-sight  packet  radio,  cellular  digital 
packet  data  (CDPD),  Iridium  satellite  modem,  and  U.S.  Navy  submarine  sonars.  The 
racom  gateway  node  links  the  Seaweb  server  to  the  undersea  network  through  standard 
TCP/IP  and  RS232  serial  protocols.  Acoustic  network  command  and  control  determines 
the  destination  of  the  data  packet  based  on  the  IP  address,  port  number,  and 
source/destination  id  numbers  of  the  acoustic  telesonar  modems  and  the  client’s  Seaweb 
subscription.  [4] 

The  servers  on  the  ship  and  undersea  vehicle  automatically  logged  the  Seaweb 
2004  network  activity  examined  in  subsequent  chapters  of  this  thesis.  The  database 
timestamps,  archives,  and  queues  all  incoming  and  outgoing  data,  client  information,  and 
network  statistics.  During  operations,  the  server  publishes  incoming  data  packets  to  the 
database  for  access  by  terrestrial  clients,  and  queues  outgoing  data  packets  to  the  database 
for  delivery  into  the  underwater  Seaweb  domain.  [4] 
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III.  EXPERIMENT  ENVIRONMENT 


This  chapter  discusses  the  environmental  variables,  including  the  historical  data 
influencing  the  Seaweb  2004  plan  and  the  measured  data  observed  during  conduct  of  the 
experiment. 

Knowledge  of  the  environment  is  vital  to  understanding  communications 
performance  and  to  the  design  of  a  successful  network  topology.  The  environment 
determines  the  characteristics  of  the  telesonar  channel  and  the  communications  link 
budget.  The  channel  is  determined  by  the  source-to-receiver  geometry,  transmission  loss, 
noise,  multipath,  and  temporal  variability.  Seaweb  2004  employs  signaling  technology 
that  is  immune  to  expected  multipath  and  temporal  variability,  as  discussed  in  the  next 
chapter. 

A  communication  link  budget  derives  from  the  source  level  of  the  transmitter,  the 
noise  level  at  the  receiver  and  the  range-dependent  transmission  loss  [16].  Seaweb  2004 
operations  are  affected  by  sound  propagation  and  ambient  noise  levels  for  the  operating 
band  of  9-14  kHz. 

A.  CHALLENGES  OF  THE  UNDERWATER  ACOUSTIC  CHANNEL 

Signals  travel  much  slower  in  underwater  acoustic  channels  than  in  conventional 
communication  channels.  For  example,  the  propagation  speed  is  five  orders  of  magnitude 
slower  than  that  of  the  radio  channel,  producing  communications  latency  and  potentially 
resulting  in  a  reduction  of  the  overall  throughput  of  the  system  [11]. 

In  addition,  the  signals  suffer  significant  losses  proportional  to  the  transmission 
range.  Transmission  loss  can  be  attributed  to  two  main  factors,  attenuation  and  geometric 
spreading.  Attenuation  is  caused  by  absorption  due  to  the  conversion  of  acoustic  energy 
into  heat.  It  increases  with  distance  and  frequency.  Geometric  spreading  refers  to  the 
diminishing  of  sound  energy  density  as  a  result  of  wavefront  expansion.  It  increases  with 
distance  at  a  rate  dependent  on  the  channel  geometry.  Two  simple  descriptions  of 
geometric  spreading  are  spherical,  which  is  seen  mainly  in  deep  ocean  water,  and 
cylindrical,  which  is  seen  in  shallow  water  and  in  ducted  channels.  [11] 
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The  spreading  characteristics  of  deep  ocean  channels  have  been  explored 
extensively  in  the  literature.  Shallow  water  channels,  however,  exhibit  greater  variability 
and  are  less  readily  described.  Signals  experience  dispersion  from  surface  and  bottom 
interactions  and  distortion  from  the  combination  of  multipaths  at  the  receiver  [9], 
Multipath  propagation  can  cause  inter-symbol  interference  (ISI)  when  the  symbol  period 
is  less  than  the  channel  impulse  response.  Horizontal  channels,  like  those  in  Seaweb,  tend 
to  experience  rather  long  multipath  spreads.  This  spread  is  predominantly  a  function  of 
the  water  depth  and  the  distance  between  the  transmitter  and  receiver  [11],  Doppler  shift 
caused  by  movement  of  a  communicating  modem  or  by  water  currents  can  significantly 
degrade  underwater  communications.  In  general,  the  acoustic  modem  needs  to  monitor 
and  correct  Doppler  shifts. 


B.  WIND  AND  SEAS 

Sound  propagation  is  influenced  by  sea  surface  conditions,  the  water  medium,  and 
bottom  characteristics.  Without  knowledge  of  all  these  features  it  is  difficult  to  predict  the 
behavior  of  sound  propagation  [11],  The  wind  speed  and  wave  heights  during  Seaweb 
2004  were  recorded  on  a  daily  basis  shown  in  Figure  6.  The  weather  conditions  steadily 
improved  through  the  experiment,  decreasing  the  ambient  noise  level  within  the  channel 
and  improving  the  communications  link  budget.  [5] 

The  noise  level  within  a  channel  directly  impacts  the  communications  link  budget. 
Most  ambient  noise  can  be  characterized  as  having  a  continuous  spectrum  and  Gaussian 
statistics.  It  is  related  to  the  movement  of  water  including  tides,  currents,  storms,  and  rain 
as  well  as  seismic  and  biologic  phenomena.  Man-made  noise  is  primarily  caused  by 
machinery  noise  (pumps,  reduction  gears,  power  plants)  and  shipping  activity.  Man-made 
noise  dominates  in  areas  of  especially  heavy  vessel  traffic  [11],  In  the  9-14  kHz  band 
used  for  telesonar  signaling,  the  ambient  noise  levels  during  Seaweb  2004  appeared  to  be 
associated  with  wind  speed  and  sea  state,  consistent  with  historical  noise  spectra 
summarized  by  Figure  7  [12],  with  elevated  levels  episodically  caused  by  shipping  and 
sonar  activity.  In  addition,  multi-user  communications  by  Seaweb  itself  increases  in-band 
noise  levels. 
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Figure  6.  The  wind  speed  and  wave  height  were  measured  on  a  daily  basis.  These 
phenomena  largely  determined  the  ambient  noise  level  within  the 
communications  channel.  Improved  Seaweb  performance  as  the  experiment 
progressed  is  partly  attributed  to  decreasing  noise  levels  [2], 


Figure  7.  Weather  conditions  greatly  impact  Seaweb  performance.  The  9-14  kHz  band  is 
impaired  by  ambient  noise  from  wind-dependent  noise,  as  shown  by  historically 
derived  noise  spectra  [12]. 
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C.  REFRACTION 

Sound-speed  profiles  describing  sound  speed  as  a  function  of  water  depth  provide 
information  that  helps  predict  telesonar  communication  ranges.  Bathymetry  or  bottom 
topology  at  the  site  also  plays  an  important  role.  The  overall  area  of  coverage  served  by 
the  grid  is  determined  by  a  combination  of  the  number  of  nodes  used,  the  distances 
between  them,  and  the  maximum  communication  range  of  the  undersea  vehicle. 

When  designing  the  planned  Seaweb  grid  of  Figure  3,  the  historical  sound-speed 
profile  shown  in  Figure  8  was  used  to  model  sound  propagation  for  the  experiment  site 
and  season. 

The  sound-speed  gradient  of  Figure  8  refracts  acoustic  energy  downward  away 
from  the  sea  surface.  The  rays  traced  in  Figure  9  show  sound  propagation  out  to  the  first 
interaction  with  the  seafloor  with  refraction  modeled  according  to  the  gradients  of  the 
historical  sound-speed  profile.  These  ray-trace  predictions  were  used  to  specify  the 
nominal  node  spacing  within  the  grid  during  experiment  planning,  assuming  conservative 
link-margin  estimates  requiring  direct-path  acoustic  communications.  Such  predictions 
afford  the  network  designer  an  opportunity  to  deploy  the  Seaweb  nodes  in  a  sparser  or 
denser  pattern  consistent  with  the  tolerance  of  expected  environmental  propagation  and 
noise  conditions.  For  communications  between  nodes  near  the  seafloor,  downward 
refraction  gives  favorable  propagation  by  virtue  of  the  long  direct-path  arcs  that  are 
supported  by  the  medium.  Because  performance  can  be  severely  degraded  by  interactions 
of  the  propagating  acoustic  signal  with  a  rough  sea  surface,  downward  refracting  channel 
conditions  also  favor  communications  from  the  undersea  vehicle  to  bottom-mounted 
nodes.  In  this  experiment,  where  reliable  link-layer  communications  supports  the 
objective  of  network-layer  performance  analysis,  direct-path  communications  is  the 
design  criteria  for  node-to-node  link-layer  spacing.  This  is  an  admittedly  conservative 
objective  given  prior  link-layer  performance  measurements,  but  the  network-layer 
performance  is  the  overriding  consideration  in  this  experiment. 
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Figure  8.  Historical  sound-speed  profile  for  the  experiment  site  indicates  a  50-meter  deep 
surface  mixed  layer  overlying  a  strong  thermocline  [6].  These  are  typical 
characteristics  of  continental  shelf  ocean  waters  in  temperate  zones. 
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Figure  9.  For  an  acoustic  transmitter  3  meters  above  the  seafloor  at  range  0,  a  fan  of  223 
rays  with  launch  angles  between  0°  and  -11.1°  are  numerically  traced  through  a 
25  5 -m  deep  stratified  medium  modeled  after  the  historical  sound-speed  profile  of 
Figure  8.  [6]. 
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So,  ray-trace  analysis  of  the  historical  sound-speed  profile  suggests  that  direct- 
path  sound  energy  would  support  node-to-node  spacing  up  to  5  km.  Direct-path 
propagation  is  a  desirable  condition  since  propagated  energy  is  less  subject  to  distortion 
and  dispersion  at  the  rough  sea  surface  boundary,  and  to  entrapment  in  surface  ducts. 
Seaweb  mission  planners  set  the  nominal  distance  at  3  km  to  ensure  direct-path  energy 
and  to  mitigate  the  less  predictable  noise  levels.  The  3-km  spacing  also  allows  for  the 
possibility  of  individual  node  failures  requiring  longer  links  to  heal  the  network. 
Moreover,  a  conservative  design  using  3-km  spacing  was  consistent  with  the  application 
of  experimental  Seaweb  technology  to  undersea  vehicle  cellular  communications,  the 
principal  objective  of  this  experiment.  It  is  expected  that  longer  links  involving  non- 
direct  path  links  are  supportable,  based  on  prior  experimentation  in  other  environments, 
but  these  links  are  not  to  be  counted  on  given  the  experimental  uncertainties  of 
propagation  and  noise  conditions. 

Five  days  prior  to  the  commencement  of  the  experiment,  during  Seaweb 
deployment  operations,  the  second  ship  obtained  conductivity-temperature-depth  (CTD) 
profiles  in  the  vicinity  of  the  network.  Sound-speed  profiles  derived  from  these  CTD 
profiles  are  plotted  in  Figure  10.  The  shape  is  generally  consistent  with  the  archival 
profile  of  Figure  8,  exhibiting  in  the  upper  water  column  a  well-defined  mixed  layer  of 
slightly-increasing  sound  speed  with  depth,  overlying  a  thermocline  with  sound  speed 
decreasing  strongly  with  depth. 

However,  because  of  turbulence  from  major  storms,  the  mixed  layer  extends  to 
about  twice  the  depth  shown  on  historical  sound-speed  profiles  for  the  area  at  this  time  of 
year.  Three  sound-speed  profiles  representing  geographically  separate  parts  of  the 
network  are  shown  for  clarity  in  Figure  11.  Differences  from  the  historical  profile  are  in 
the  depth  of  the  surface  mixed  layer  and  thermocline.  The  mixed  layer  depth  varies 
between  70  and  125  meters,  compared  with  50  meters  in  the  historical  profile.  Some 
profiles  show  perturbations  from  a  constant  gradient  in  the  thermocline  and  evidence  of  a 
bottom  layer  having  a  gradient  distinct  from  that  of  the  thermocline. 

These  measurements  provided  the  acoustic  propagation  information  intended  to 
influence  the  final  grid  design,  had  the  deployment  of  the  operational  grid  not  been 
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accelerated  by  the  compressed  schedule.  For  the  bottom-to-bottom  acoustic  propagation, 
as  seen  in  Figure  12,  the  observed  sound-speed  profiles  should  support  direct-path 
telesonar  ranges  to  about  2400  meters,  only  half  of  that  predicted  from  historical 
conditions  typical  for  that  time  of  year.  The  nominal  distance  of  the  nodes  had  already 
been  set  at  3000  meters  as  a  conservative  spacing  choice,  and  the  actual  communications 
link  budget  appeared  to  be  adequate  for  reliable  communications  despite  the  less 
favorable  propagation  environment.  Nevertheless,  these  weather  conditions  demonstrate 
the  inherent  channel  dependence  of  acoustic  communications,  and  the  variability  that 
affects  the  propagation  medium. 


Sound  Speed  (m/s) 

Figure  10.  Sound-speed  profiles  measured  during  the  experiment  in  the  area  serviced 

by  the  Seaweb  2004  network  show  considerable  variability.  [6] 
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Sound  Speed  (m/s) 

Figure  11.  Selected  sound-speed  profiles  showing  variation  of  depth  of  mixed  layer 

and  thermocline  and  localized  presence  of  bottom  layer.  Locations  refer  to 
Seaweb  node  addresses  charted  on  Figure  3. 
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Figure  12.  The  sound-speed  profile  measured  in  the  center  of  the  grid  near  Node  R17 

is  the  basis  for  the  above  ray  traces.  There  are  231  beams  with  launch  angles 
between  0°  and  -13°.  A  255-m  depth  is  modeled  for  comparison  with  Figure  9. 
[6] 
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IV.  SEAWEB  2004  COMMUNICATIONS 


The  communications  architecture  utilized  in  Seaweb  2004  follows  the 
International  Standards  Organization’s  Open  Systems  Interconnection  (ISO/OSI)  model 
summarized  in  Figure  13.  This  reference  model  is  designed  to  allow  for  efficient 
communications  through  seven  subtask  layers  arranged  in  a  hierarchical  structure.  Each 
layer  of  the  model  presents  simplified  information  for  further  handling  at  the  next  higher 
layer.  This  chapter  describes  the  Seaweb  2004  implemention  of  the  physical  and  link 
layers.  The  next  chapter  examines  the  Seaweb  2004  network,  transport,  and  session 
layers. 


Application 


Presentation 


Session 


Transport 


Network 


Link 


Physical 


Figure  13.  Seaweb  underwater  network  is  an  implementation  of  the  physical,  link  and 

network  layers  of  the  OSI  model  [7,  8].  The  upper  three  layers  are 
mission/application  specific,  and  are  normally  implemented  by  the  Seaweb 
clients. 


A.  PHYSICAL  LAYER 

The  physical  layer  is  concerned  with  transmitting  an  unstructured  bit  stream 
through  the  physical  medium.  It  deals  with  the  mechanical,  electrical,  functional,  and 
procedural  characteristics  to  access  the  physical  medium. 

1.  M-ary  Frequency  Shift  Keying  (MFSK) 

For  Seaweb  2004,  the  physical  layer  is  based  on  M-ary  Frequency  Shift  Keying 
(MFSK)  modulation  of  acoustic  energy  in  the  9-14  kHz  band.  This  modulation  is  favored 
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for  acoustic  communications  for  its  inherent  tolerance  of  time  spread  induced  by 
multipath  and  Doppler  spread  induced  by  temporal  variability.  Another  advantage  of 
MFSK  is  the  ease  of  implementing  receiver  algorithms  on  a  fixed-point  digital  signal 
processing  (DSP)  chip.  The  general  analytic  expression  for  MFSK  modulation  is 


for  0  <  t  <  T;  i=l...M  ,  where  the  frequency  term  coi  has  M 


discrete  values,  and  the  phase  term ,</>,  is  an  arbitrary  constant.  The  MFSK  waveform 
changes  frequency  combinations  from  one  symbol  to  the  next.  These  transitions  can  be 
abrupt  because  there  is  no  requirement  that  the  phase  be  continuous.  In  practice,  M  is 
usually  equal  to  a  power  of  2  and  all  M  signals  in  the  set  are  orthogonal  signals,  i.e. 

T 

jV  (tjs  f  (  t  )dt  =  0;i  ^  j .  Frequency  spacing  requirements  must  be  set  to  ensure 

0 


orthogonality  [14].  The  Seaweb  implementation  of  MFSK  involves  the  use  of  128  tones 
to  attain  a  raw  rate  of  2400  bits/s. 

2.  Forward  Error  Correction  Coding 

Whether  dealing  with  benign  or  impaired  channels,  received  waveforms  can  have 
signal  components  lost  due  to  low  signal-to-noise  ratios,  fading,  or  interference.  To 
mitigate  these  issues,  the  introduction  of  redundancy  within  a  signal  by  means  of  coding, 
in  effect,  distributes  the  information  contained  in  a  single  “bit”  of  data  across  sub¬ 
channels  aiding  in  reconstruction  of  the  signal  [14].  This  is  called  error  correction  coding. 
Seaweb  utilizes  forward  error  correction  (FEC),  redundant  bits  that  are  placed  within  a 
packet  to  aid  in  reconstruction  and  decoding  if  the  signal  is  corrupted. 


It  is  especially  desirable  within  wireless  links  to  employ  a  form  of  error  correction 
that  allows  the  receiver  to  correct  errors  in  an  incoming  transmission  on  the  basis  of  the 
bits  in  that  transmission.  By  adding  redundancy  to  the  transmitted  message,  it  is  possible 
for  the  receiver  to  deduce  what  the  original  message  was,  even  in  the  presence  of  bit 
errors. 


The  raw  signaling  rate  of  2400  bits/s  is  reduced  to  an  effective  information  bit- 
rate  based  on  the  desired  degree  of  coding,  redundancy  and  channel  tolerance.  Seaweb 
2004  utilized  convolutional  error  correction  encoding  at  a  14  rate.  Additional  redundancy 
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measures  may  be  invoked  to  strengthen  the  signaling  at  the  expense  of  net  throughput.  A 
nominal  information  bit-rate  of  800  bits/s  was  planned  with  the  ability  to  decrease  to  300 
bits/s  if  prevailing  channel  conditions  warranted.  In  the  actual  experiment,  the  800  bits/s 
information  bit-rate  was  found  to  be  reliable. 

3.  Transmission  Optimization 

The  Seaweb  design  is  gradually  incorporating  the  ability  to  continually  probe  the 
channel,  measuring  the  scattering  function,  the  mathematical  expression  that  describes 
the  spreading  of  signal  energy  in  the  time  and  frequency  domains.  A  handshaking 
process,  discussed  in  section  B,  then  optimizes  transmission  parameters  in  a  process 
called  adaptive  modulation.  The  transmission  parameters  to  be  tuned  through  this  process 
include  source  level,  modulation,  coding,  and  bit-rate.  [15] 


B.  LINK  LAYER 

The  link  layer  provides  mechanisms  for  the  reliable  transfer  of  information 
through  a  physical  link.  Seaweb  implements  these  mechanisms  through  the  use  of 
compact  9-byte  utility  packets.  Even  when  in  an  energy-conserving  sleep  state,  nodes  are 
capable  of  receiving  utility  packets  that  perform  functions  such  as  link  establishment, 
automatic  repeat  request,  node-to-node  ranging,  and  return  receipts.  Future  link  layer 
capabilities  will  support  adaptive  modulation  [15]  and  network  initialization  functions. 
Figures  14  and  15  describe  some  link-layer  mechanisms  employed  in  Seaweb  2004  [2], 


Node  A  Node  B 


Figure  14.  Seaweb  link-layer  handshake  protocol  for  data  transfer  involves  Node  A 

initiating  a  request-to-send  (RTS)  utility  packet.  So  addressed,  Node  B  awakens 
and  demodulates  the  RTS.  Node  B  responds  to  A  with  a  clear-to-send  (CTS) 
utility  packet  [2,  8]. 
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Node  A 


Node  B 


1.  Node  A  initiates  a 
link-layer  dialog  with 
Node  B. 

3.  Node  A  transmits  a 
4000-byte  Data  packet 
using  16  256-byte 
subpackets,  each  with 
an  independent  CRC. 


6.  Node  A  retransmits 
the  4  subpackets 
specified  by  the  SRQ 
mask. 


8.  Node  A  retransmits 
the  1  subpacket 
specified  by  the  SRQ. 


2.  Node  B  is  prepared  to  receive  a  large  Data 
packet  as  a  result  of  RTS/CTS  handshaking. 


4.  Node  B  receives  12  subpackets  successfully; 

4  subpackets  contained  uncorrectable  bit  errors. 

5.  Node  B  issues  an  SRQ  utility  packet,  including 
a  16-bit  mask  specifying  the  4  subpackets  to  be 
retransmitted. 

7.  Node  B  receives  3  of  the  4  packets 
successfully  (future  implementation  of  cross-layer 
time-diversity  processing  will  recover  4  of  4).  B 
issues  an  SRQ  for  the  remaining  subpacket. 

9.  Node  B  successfully  receives  and 
processes  Data  packet. 


Figure  15.  Selective  automatic  repeat  request  (SRQ)  is  a  link-layer  mechanism  for 

reliable  transport  of  large  data  files  between  neighboring  nodes  even  when  the 
physical  layer  suffers  high  bit-error  rate.  Purple  arrows  depict  Seaweb  utility 
packets  including  RTS,  CTS,  MAC  header  (HDR),  and  SRQ.  Red  arrows  are  Data 
subpackets  [2,  8]. 
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V.  SEAWEB  2004  NETWORKING 


The  network  layer  controls  the  data  routing  and  switching  technologies  used  to 
connect  systems.  The  transport  layer  involves  source-to-destination  addressing  and 
information  assurance  mechanisms.  Seaweb  implements  these  network  and  transport 
capabilities  on  the  modem.  For  Seaweb  2004,  a  session  layer  protocol  was  instituted  to 
accommodate  unique  characteristics  of  a  mobile  node  operating  in  a  fixed  grid. 
Performance  metrics  include  availability,  reliability,  throughput,  transit  delay,  transit 
jitter,  and  connection  establishment  delay. 


A.  NETWORK  ROUTING 

The  network  layer  determines  how  messages  are  routed  through  the  network  from 
source  node  to  destination  node.  As  introduced  in  the  previous  chapter,  Seaweb 
communications  involves  utility  packets  and  data  packets.  The  utility  packets  are  9  bytes, 
while  Seaweb  2004  data  packets  may  be  up  to  2  kilobytes.  The  utility  packets  of  interest 
at  the  network  layer  are  Receipts  (RCPT)  and  Acknowledgments  (ACK).  Figure  15 
shows  the  link  layer  movement  of  a  data  packet  from  node  to  node,  representing  just  one 
hop  in  a  network  layer  route  that  may  have  many  such  hops  connecting  source  to 
destination  node. 

Seaweb  2004  did  not  employ  an  embedded,  dynamic  routing  algorithm.  Instead, 
the  Seaweb  administrator  specified  fixed  routing  by  means  of  data  structures  maintained 
at  each  node.  These  distributed  data  structures  are  the  Seaweb  routing  tables  and  neighbor 
tables.  In  Seaweb  2004  these  tables  were  managed  and  manipulated  only  by  the  Seaweb 
administrator  aboard  the  ship. 

Routes  are  derived  from  a  combination  of  the  three  routing  approaches  used  in  the 
development  of  internet  routing  protocols:  distance-vector  routing,  link-state  routing,  and 
path-vector  routing.  Distance-vector  routing  requires  that  each  node  exchange 
information  with  its  neighboring  nodes.  Each  node  then  maintains  a  table  of  link  costs  for 
each  directly  attached  node,  and  next-hop  vectors  for  each  destination  node.  A  link-state 
router  determines  the  link  cost  on  each  of  its  network  interfaces,  and  advertises  these 
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settings  to  all  of  the  nodes  within  the  system.  The  individual  nodes  then  monitor  the  link 
costs.  With  path-vector  routing,  information  is  provided  about  which  nodes  can  be 
reached  via  a  certain  node.  It  does  not  account  for  the  distance  or  cost  estimate  [14]. 

The  Seaweb  2004  network  required  the  administrator  to  estimate  all  of  the  above 
parameters  and  combine  them  in  an  ad  hoc  fashion  to  determine  which  routing  scheme 
would  best  support  message  delivery.  Seaweb  routing  will  be  automated  as  the 
technology  evolves,  and  the  Seaweb  2004  utility  packet  formats  and  network  layer  data 
structures  anticipate  that  evolution. 


Figure  16.  The  initial  deployed  Seaweb  operational  grid  included  2  racom  gateway 

buoys  and  39  telesonar  repeater  nodes.  The  gateway  buoys  are  equipped  with 
FreeWave  line-of-sight  radio  links.  The  ship  hosted  the  Seaweb  command  center, 
including  the  Seaweb  server  with  FreeWave  interface  [2], 
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During  Seaweb  2004,  the  ship  was  responsible  for  monitoring  the  performance  of 
each  node  and  the  characteristics  of  each  link,  determining  when  and  if  the  routing  tables 
needed  to  be  changed.  When  each  node  was  deployed  it  had  an  initial  routing  table 
programmed  within  the  modem.  The  original  routing  configuration  is  shown  in  Figure  16. 

Channel/link  characteristics  changed  throughout  the  experiment  as  a  result  of 
varying  noise  levels.  As  seen  in  Figure  6,  during  the  first  five  days  of  the  experiment, 
high  winds  and  seas  elevated  the  noise  level,  and  decreased  the  link  budget.  Channel/link 
characteristics  were  also  affected  by  trawling  impact,  examined  in  subsequent  chapters. 
Nevertheless,  a  reliable  800  bits/s  physical  layer  was  available  throughout  the 
experiment. 

Upon  successfully  reaching  the  destination  node,  if  the  return  receipt  flag  is  set  in 
the  data  packet  header,  the  transport  layer  automatically  generates  a  return  receipt  and 
routes  it  back  to  the  source  node  following  an  efficient  and  reliable  RCPT/ACK  link- 
layer  mechanism. 


B.  MOBILE  NODE  INTEGRATION 

Extreme  channel  variability  between  moving  nodes  is  a  major  limitation  for 
mobile  underwater  communication  systems.  In  addition  to  the  motion-induced  pulse 
compression  and  dilation  of  received  signals,  the  channel  geometry  and  multipath 
structure  change  rapidly,  limiting  applicability  of  receivers  requiring  significant  channel 
coherence.  The  Seaweb  2004  physical  layer  was  relatively  immune  to  these  effects,  by 
virtue  of  non-coherently  processed  MFSK  modulation  and  special  measures  for  Doppler 
tolerance. 

A  more  serious  challenge  is  the  fact  that  the  undersea  vehicle  in  Seaweb  2004  was 
not  an  omni-directional  receiver,  unlike  the  nodes  of  the  fixed  grid.  The  undersea  vehicle 
suffers  as  a  receiver  when  its  own  hull  obstructs  arriving  sound  energy.  These  outages  are 
dependent  on  its  own  orientation  in  relationship  to  the  direction  of  incoming  signal 
propagation.  Additionally,  the  undersea  vehicle  is  a  relatively  noisy  receiver  because  of 
flow  noise,  propeller  noise,  and  other  mechanical  noise.  These  combined  factors  make 
the  mobile  node  a  disadvantaged  receiver  compared  to  the  fixed  node. 
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C.  SESSION  PROTOCOL 

The  state  of  the  art  of  Seaweb  2004  mobile  connectivity  compelled  the  use  of  a 
session-layer  protocol  requiring  the  undersea  vehicle  to  initiate  network-layer  dialogs. 
The  mobile  node  would  declare  the  nearest  node  to  be  the  cellular  address,  and  would 
access  the  Seaweb  route  to  the  destination  node  via  the  cellular  node.  When  the  ship 
received  the  initiating  message  (data  packet),  it  would  reply  with  a  response  message 
(data  packet)  via  the  reciprocal  route  to  the  cellular  node  indicated  within  the  initiating 
message,  and  the  cellular  node  would  directly  address  the  mobile  node.  Upon  receiving 
the  response,  the  Seaweb  modem  on  the  undersea  vehicle  would  immediately  and 
automatically  return  a  receipt  to  the  ship,  again  via  the  cellular  address  and  the  fixed 
route.  The  Seaweb  2004  session-layer  protocol  is  summarized  graphically  in  Figure  17. 


✓ 


✓TV  Response  message 
'  s  ' 

N 

Initiating  message 


^Return  receipt 


Undersea  Vehicle 


Undersea  Vehicle 


Figure  17.  The  communications  protocol  was  such  that  the  undersea  vehicle  would 

initiate  all  communications.  The  message  flows  through  the  grid,  ultimately 
reaching  the  destination  node,  i.e.,  the  gateway  buoy.  The  ship  would  reply  with  a 
response  message  delivered  through  the  grid.  Then  the  undersea  vehicle  would 
send  a  return  receipt  to  the  ship  through  the  grid.  The  Seaweb  network  layer 
routes  the  data  packet  through  the  grid  based  on  the  destination  address  and  the 
routing  tables  [2], 
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VI.  SEAWEB  2004  NETWORK  GRID 


A.  DEPLOYMENT 

The  first  step  in  implementing  the  Seaweb  2004  cellular  grid  was  to  perform  in¬ 
air  networking  tests  at  an  ashore  facility.  These  tests  occurred  many  days  prior  to  the  pilot 
grid  deployment,  and  exercised  message  routing  through  the  actual  experiment  hardware. 
The  procedure  involves  physically  arranging  nodes  adjacent  to  their  neighbor  nodes  in 
the  grid.  Test  messages  are  then  sent  from  source  to  destination  via  the  intended 
communications  route  through  the  network.  This  process  enables  operators  to  diagnose 
and  fix  potential  networking  and  mechanical  problems  prior  to  deploying  the  Seaweb 
nodes  in  the  water.  After  in-air  testing  was  completed,  all  acoustic  releases  were 
assembled  and  rigged  for  deployment.  Forty-seven  telesonar  repeater  nodes  and  six 
racom  gateway  buoys  were  then  loaded  aboard  the  second  ship  and  secured  for  the 
underway  transit  to  the  experiment  site  on  the  outer  continental  shelf. 

Six  days  prior  to  the  commencement  of  the  experiment,  a  Seaweb  pilot  network 
consisting  of  7  repeater  nodes  and  1  racom  gateway  buoy  was  deployed  as  charted  in 
Figure  18.  Basic  ringing  out  of  the  grid  indicated  adequacy  of  the  node-to-node  spacing 
and  grid  design. 

Then,  during  the  afternoon  and  evening  of  the  same  day,  the  second  ship  deployed 
an  additional  32  repeater  nodes  and  1  racom  buoy,  forming  the  operational  grid  of  39 
repeater  nodes  and  2  racom  gateway  nodes  charted  in  Figure  19.  Based  on  time  reports 
collected  from  the  second  ship,  the  average  deployment  time  required  per  node  was  just 
20  minutes,  including  node-to-node  transit  time  [2], 

Full  deployment  of  the  operational  grid  represented  an  accelerated  evolution 
driven  by  several  constraints,  including  a  compressed  schedule,  incoming  inclement 
weather,  and  avoidance  of  interference  with  other  experiment  platforms  operating  in  the 
same  area.  A  further  impact  of  the  accelerated  schedule  was  the  omission  of  a  planned  3 
days  of  end-to-end  network  testing  between  each  node  and  the  racom  gateway.  The 
operational  network  did  not  benefit  from  this  pre-experiment  checkout  process  and  any 
fine-tuning  that  might  have  ensued. 
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Figure  18.  The  Seaweb  pilot  network  was  a  subset  of  the  proposed  operational 

network.  It  consisted  of  7  repeater  nodes  at  positions  Rll,  R12,  R13,  R14,  R15, 
R16,  and  R17  and  1  racom  gateway  buoy  at  position  Gl.  The  circles  plotted  here 
show  conservative  communications  range  estimates  for  each  node — note  the 
shorter  range  allowed  for  Gl  where  the  telesonar  transducer  is  less  than  50  meters 
below  the  sea  surface  and  therefore  subject  to  shorter  direct-path  ranges  to 
seafloor  stations.  The  testing  of  the  pilot  grid  by  the  ship  moored  at  station  “RV1” 
and  measurements  of  the  prevailing  environmental  conditions  by  the  second  ship 
reduced  risks  for  the  final  network  architecture  shown  in  Figure  19  [2], 


As  part  of  the  deployment  process,  the  second  ship  moored  2  racom  gateway 
buoys  in  the  Southwestern  portion  of  the  network.  The  racom  buoys  require  a  more 
intensive  preparation  process,  but  took  only  6-8  minutes  to  deploy.  The  moored  racom 
buoys  handled  the  high  seas,  high  winds,  and  strong  currents  at  the  experiment  site  during 
this  maiden  deployment,  however  brief. 

After  deploying  the  bed  of  repeater  nodes,  it  was  decided  that  the  second  ship 
would  recover  the  two  racom  gateway  buoys.  Warnings  of  inclement  weather  gave 
concern  that  the  buoys  would  have  been  unnecessarily  at  risk.  Sea  states  were  too  high 
for  use  of  a  RHIB  to  assist  in  the  buoy  recovery,  so  the  ship  went  it  alone.  Both  buoys 
were  retrieved,  but  major  damage  incurred  by  the  heavy-handed  recovery  process 
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rendered  them  useless  for  the  rest  of  the  experiment.  Both  moorings  were  lost,  both 
telesonar  transducers  were  lost,  both  telesonar  transducer  cables  were  damaged  beyond 
repair,  one  Iridium  antenna  was  lost,  one  GPS  antenna  was  damaged,  and  one  FreeWave 
antenna  was  lost.  Visual  inspection  indicated  that  the  seas  had  not  damaged  the  buoy 
portion,  however  [3].  This  indicated  that  the  new  racom  buoys  are  survivable  in  six  to 
nine  foot  seas. 

The  most  serious  loss  during  the  racom  recovery  was  the  two  telesonar  transducer 
cables.  Although  the  second  ship  had  four  additional  new  buoys  on  deck,  they  only  had 
one  50-meter  telesonar  transducer  cable.  This  was  a  result  of  the  short  contract  schedule 
in  combination  with  the  relatively  long  lead-time  on  the  cables.  Therefore,  a  20-meter 
cable  was  fabricated  by  joining  two  available  10-meter  cables.  If  this  had  not  worked,  the 
contingency  plan  had  been  to  use  a  telesonar  transducer  deployed  over  the  side  of  the 
ship  in  place  of  the  racom  gateway  buoy  [18]. 

One  day  prior  to  commencing  experimentation,  the  second  ship  deployed  two 
racom  gateway  buoys  designated  Gib  and  G2b  in  the  vicinity  of  the  two  that  were 
recovered  previously.  To  avoid  entanglement  with  remnants  of  Gla  and  G2a,  the  new 
buoy  moorings  were  displaced  slightly  from  the  earlier  posits.  Gib  stood  approximately 
500  meters  east  of  Gla  and  G2b  approximately  500  meters  north  of  G2a  [3,  18]. 

A  problem  at  racom  buoy  G2b  with  the  telesonar  transducer  or  telesonar  transduer 
cable  prevented  telesonar  communications  and  was  identified  the  same  day  of 
deployment.  It  was  felt  that  Racom  gateway  buoy  G2b  needed  to  be  recovered  and 
serviced.  The  failure  was  isolated  and  confirmed  by  various  means,  including  testing  via 
direct  telesonar  communications  from  RV 1  using  an  over-the-side  telesonar  deck  unit.  It 
was  determined  that  when  daylight  and  seas  permitted,  the  second  ship  would  execute  a 
controlled  recovery.  All  Seaweb  repeater  nodes  were  functional  with  exception  of  Nodes 
20  and  35.  They  responded  to  Seaweb  utility  packets,  but  had  difficulty  with  higher  bit- 
rate  data  packets.  This  was  thought  to  be  due  to  the  transducers  being  occluded  by  a 
fouled  or  tangled  rigging.  For  this  reason,  the  Seaweb  routing  avoided  Node  20  for  the 
first  day  of  testing. 
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Figure  19. 


The  actual  grid  of  repeater  nodes  was  deployed  eight  days  prior  to  the 
beginning  of  the  exercise.  Due  to  inclement  weather,  end-to-end  testing  of  the 
grid  did  not  take  place.  Since  the  three  days  of  planned  testing  did  not  happen, 
many  troubleshooting  types  of  errors  were  fixed  during  the  ten  days  of  testing. 
This  is  one  of  the  reasons  for  steady  performance  improvements  during  the  course 
of  the  experiment  [2], 


B.  NETWORK  REROUTING 

During  the  post-experiment  recovery  of  the  repeaters  it  was  confirmed  that  the 
central  column  of  the  Seaweb  grid  suffered  major  trauma  by  trawling  activity.  The 
inability  to  recover  8  of  the  repeater  nodes  is  largely  attributable  to  the  trawling  activity, 
with  a  variety  of  failure  modes  described  in  greater  detail  in  Section  C.  Despite  this 
damage,  the  Seaweb  administrators  on  the  ship  incrementally  established  connectivity 
within  the  grid.  Through  remote  polling  and  remote  control  of  the  Seaweb  network  layer, 
administrators  healed  the  network.  This  significant  achievement  of  the  exercise 
anticipates  future  automatic  initialization  of  ad  hoc  Seaweb  grids,  including  the 
assimilation  of  nodes  deployed  by  various  platform  types  over  time,  including  Unmanned 
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Aerial  Vehicle  (UAV),  Unmanned  Surface  Vehicle  (USV),  Unmanned  Undersea  Vehicle 
(UUV),  SEAL  Delivery  Vehicle  (SDV),  Maritime  Patrol  Aircraft  (MPA),  attack 
submarines  (SSN),  etc. 


Day-to-day  changes  in  the  network  routing  are  shown  in  Figure  20. 


Figure  20.  Day-by-day  changes  within  the  network  were  accomplished  by  remote 

polling  and  control  from  the  ship.  These  charts  demonstrate  the  impact  routing 
can  have  on  the  overall  performance  of  the  network.  They  also  support 
suggestions  that  the  network  can  be  healed  post-major  trauma.  Initial  routing 
relied  greatly  on  the  center  300-meter  contour  column  of  nodes.  In  hindsight,  it  is 
clear  that  had  routing  been  accomplished  sooner  in  the  manner  accomplished  on 
Day  9  (Figure  21)  with  the  center  nodes  as  leaf  nodes,  Seaweb  2004  performance 
would  have  been  improved. 
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1.  Day  One 

During  the  first  day  of  operations  connectivity  with  the  racom  buoy  via  the 
FreeWave  line-of-sight  radio  link  was  occasionally  lost  for  long  periods  of  time  as  the 
ship  ventured  away  from  the  buoys.  A  FreeWave  range  of  4  nmi  or  less  was  needed  for 
the  ship  to  maintain  uninterrupted  connectivity  since  the  low-profile  racom  buoy  was 
periodically  within  a  trough  with  the  radio  link  momentarily  occluded  by  a  wave  crest.  In 
subsequent  days,  the  ship  was  moored  in  position  just  2  nmi  from  the  racom  moorings.  At 
this  range  the  ship  maintained  solid  uninterrupted  connectivity  with  the  racom  buoy. 
Testing  of  the  grid  continued  throughout  day  1.  This  included  adjusting  bit-rates  from 
300  to  800  bits/s,  adjusting  routes,  and  setting  power  levels.  It  is  important  to  again  note 
that  the  original  schedule  allowed  for  up  to  3  days  to  ring  out  the  grid,  in  conjunction 
with  node  servicing  support  from  the  second  ship.  Due  to  the  inclement  weather  and  all 
ships  being  sent  back  to  port,  this  end-to-end  testing  did  not  happen. 

The  second  ship  had  four  spare  telesonar  repeater  nodes,  four  pairs  of  acoustic 
releases,  forty-one  weights,  and  one  spare  float  onboard.  Four  additional  racom  buoys, 
one  ready  for  deployment,  were  on  deck.  Transducer  cables  proved  to  be  the  limiting 
factor  for  racom  buoy  availability.  Two  of  the  50-meter  cables  were  severed  during  the 
aforementioned  recovery  and  the  third  was  on  the  inoperative  deployed  racom.  The 
working  deployed  racom  had  a  makeshift  50-m  cable  created  during  the  unexpected 
anchorage  by  splicing  a  50-meter  deck  unit  cable  onto  the  stub  of  one  of  the  severed 
cables. 

There  was  not  a  significant  amount  of  rerouting  of  the  network  on  day  one,  since 
the  network  needed  to  remain  available  for  use  by  the  undersea  vehicle.  With  limited 
Seaweb  personnel  on  the  ship,  the  Seaweb  server  could  not  be  manned  around  the  clock. 
Seaweb  personnel  rested  during  the  afternoon  and  evening  hours  in  order  to  prepare  for 
the  day  1  events.  Occasionally  the  communication  link  between  the  ship  and  the  racom 
buoy  would  drop  out  due  to  high  seas  and  maneuvering  of  the  ship.  These  outages 
required  reestablishment  of  the  communications  session  and  interrupted  Seaweb  service. 
Outages  usually  were  on  the  order  of  minutes,  but  in  one  case  was  over  30  minutes. 
Without  access  to  the  gateway,  it  was  difficult  to  maintain  and  monitor  all  aspects  of  the 
network. 
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The  schedule  of  events  demanded  that  event  1  commence  despite  high  seas  and 
winds  that  presented  unfavorable  noise  conditions  for  acoustic  communications.  During 
the  event,  the  ship  bridge  reported  seas  up  to  12  feet.  The  undersea  vehicle  operated  near 
the  sea  surface  which  disadvantaged  the  vehicle  as  a  receiver,  primarily  because  of  high 
noise  levels,  but  also  because  of  the  deep  mixed  layer  and  the  aspect-dependent  mounted 
transducer. 

The  ship  could  communicate  with  Nodes  20  and  35  with  Seaweb  utility  packets, 
but  not  with  data  packets.  Seaweb  administrators  rerouted  network  traffic  around  20,  but 
only  partially  rerouted  around  35.  Meanwhile,  plans  for  the  deployment  of  a  third  racom 
buoy  to  back  up  the  one  functioning  racom  unit  were  developed.  High  seas  would  prove 
to  stall  this  deployment  until  day  four  of  experimentation. 

When  the  grid  was  deployed  the  network  relied  heavily  on  the  left  and  center 
columns  of  nodes.  Both  were  routed  straight  down  to  the  gateway.  The  right  column  was 
routed  in  as  leaf  nodes.  Because  of  lack  of  confidence  in  Node  20,  the  southernmost 
portion  of  the  grid  was  rerouted.  As  well,  Nodes  35  and  47  were  not  yet  operating 
properly.  Therefore,  in  hindsight,  the  northeastern  portion  of  the  grid  was  deemed 
inoperable  for  the  day  of  operations  and  testing. 

The  first  message  sent  by  the  undersea  vehicle  was  via  Node  42  in  the  most 
northerly  section  of  the  grid.  The  ship  sent  a  reply,  but  a  return  receipt  was  not  received 
at  the  ship.  The  undersea  vehicle  was  deemed  to  be  a  disadvantaged  receiver  when 
operating  at  shallow  depths,  especially  in  high  seas  where  ambient  noise  in  the  9-14  kHz 
Seaweb  band  is  dominated  by  wind  and  sea-surface  turbulence.  Compounding  this  was 
the  strong  and  deep  mixed  layer.  When  the  undersea  vehicle  operated  at  lower  depths  it 
would  experience  better  communications.  Despite  adverse  conditions,  data  packets  from 
the  undersea  vehicle  were  successfully  transmitted  to  the  ship  via  cellular  Nodes  42,  24, 
22,  22,  19,  19,  21,  21,  21,  and  22,  consecutively.  All  activity  was  logged  and  time- 
stamped  by  the  Seaweb  server  on  the  ship. 
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2.  Day  Two 

On  Day  2,  the  network  seemed  to  have  been  hindered  by  more  than  just  the  12- 
foot  seas  and  30-kt  Northerly  winds.  Due  to  an  apparent  malfunction  within  Node  25,  the 
majority  of  the  network  could  not  be  accessed.  At  the  time,  it  was  unclear  what  had 
happened  to  Node  25,  other  than  the  fact  that  it  was  not  operating  properly.  In  retrospect, 
all  evidence  indicates  that  Node  25  was  lost  to  trawling  on  this  day.  As  seen  in  Figure  20, 
without  Node  25,  the  entire  northern  portion  of  the  grid  was  inoperable.  In  order  for 
communications  to  resume,  it  was  necessary  to  reroute  around  25.  As  well,  the  ship’s 
moor  had  become  unstable  and  the  ship  was  moving  within  the  buoy  box  causing  Free 
Wave  radio  connectivity  issues  with  the  racom  gateway  buoy. 

During  Day  2,  messages  arriving  from  the  undersea  vehicle  did  not  reveal  the 
Seaweb  cellular  address  as  intended,  thus  thwarting  the  intended  response  messaging  in 
the  Seaweb  2004  session  layer  protocol.  This  cellular  address  is  embedded  in  the  Seaweb 
header  utility  packet  and  a  simple  Seaweb  modem  firmware  change  would  be  required  to 
extract  it.  Had  the  schedule  permitted,  end-to-end  connectivity  testing  would  have 
revealed  this  problem  before  experiment  commencement.  A  workaround  involved 
reprogramming  the  undersea  vehicle  to  explicitly  declare  the  cellular  address  in  the  body 
of  transmitted  messages.  The  network  issues  experienced  this  day  allowed  only  one  data 
packet  from  the  undersea  vehicle  to  be  transmitted  to  the  ship  via  cellular  Node  22. 

3.  Day  Three 

Day  3  brought  successful  bidirectional  communications.  The  ship  communicated 
successfully  with  all  deployed  nodes  in  the  grid  with  the  exceptions  of  Nodes  23  and  25. 
Both  nodes  were  thought  to  have  failed,  and  in  fact  were  probably  trawled  out.  Therefore, 
a  plan  for  replacement  was  developed.  Upon  replacement  of  the  repeater  nodes,  the 
second  ship  was  to  deploy  an  additional  racom  buoy  in  the  same  general  area  as  the 
others  as  a  backup  gateway  node,  and  if  time  permitted,  the  ship  would  also  use  a 
telesonar  deck  unit  for  direct  interrogation  and  reprogramming  of  Nodes  37,  38,  39,  40, 
41,  and  42.  It  is  important  to  note  again,  that  if  time  and  weather  had  allowed,  direct 
interrogation  and  reprogramming  of  nodes  would  have  been  completed  days  earlier 
during  end-to-end  testing. 
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During  Day  3  numerous  routing  and  performance  issues  in  the  grid  that  would 
normally  have  been  corrected  prior  to  the  exercise  were  resolved  with  the  aid  of  the 
second  ship.  Rerouting  was  very  successful.  At  the  end  of  Day  3  only  four  nodes  were 
unavailable  due  to  a  lingering  issue  with  Node  36.  Data  packets  from  the  undersea 
vehicle  were  successfully  transmitted  to  the  ship  via  cellular  Nodes  17,  17,  20,  18,  18,  17, 
17,  20,  19,  19,  17,  20,  26,  44,  44,  44,  27,  31,  47,  48,  48,  49,  48,  and  48,  consecutively. 

4.  Day  Four 

Finally,  on  the  fourth  day  of  the  experiment,  mild  winds  and  seas  allowed  the 
second  ship  to  deploy  the  additional  racom  buoy  in  the  vicinity  of  the  other  two  gateways 
as  a  backup  gateway  node.  Racom  buoy  G2b  was  left  in  the  water  because  it  remained 
functional  in  terms  of  the  FreeWave  link  and  as  a  telesonar  receiver,  and  because 
recovering  it  might  have  endangered  the  other  nearby  racom  buoys.  The  second  ship 
attempted  to  recover  Node  23,  but  actuation  of  the  acoustic  release  did  not  result  in  the 
surfacing  of  the  node.  This  could  have  been  because  of  the  node  depth,  or  because  of  the 
trawling  of  the  grid.  Due  to  time  constraints,  recovery  of  Node  25  was  not  attempted. 
Node  55,  the  replacement  for  the  two  nodes,  was  deployed  and  successfully  assimilated 
into  the  grid.  Two  trawling  vessels  were  observed  operating  within  the  Seaweb  grid 
during  Node  55  deployment,  further  supporting  suspicions  of  trawling  down  the  center 
column  of  nodes.  It  is  believed  that  Nodes  23  and  25  were  both  removed  from  the  grid 
during  earlier  trawling. 

Communications  were  further  improved  by  the  lower  undersea  ambient  noise 
during  day  four  of  testing,  but  issues  with  Nodes  32  and  33  prevented  traffic  flow  from 
Nodes  34  and  35  north.  Data  packets  from  the  undersea  vehicle  were  successfully 
transmitted  to  the  ship  via  cellular  Nodes  45,  26,  28,  24,  20,  44,  24,  and  20, 
consecutively. 

5.  Day  Five 

Day  5  brought  the  return  of  high  ambient  noise  levels  with  increasing  winds  and 
seas.  The  ship  communicated  successfully  with  all  deployed  nodes  in  the  grid.  Node  55 
deployed  on  Day  4  was  functioning,  but  with  weak  performance.  On  Day  5  no  packets 
were  sent  to  it  or  from  it,  therefore  it  was  considered  out  of  the  network.  Because  Nodes 
23,  25,  and  55  were  concentrated  in  one  particular  area,  an  area  with  somewhat  more 
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bathymetric  gradient  than  elsewhere  in  the  grid,  it  was  erroneously  hypothesized  at  the 
time  that  this  telesonar  dead  zone  was  a  result  of  seafloor  properties. 

Minor  maintenance  on  the  grid  took  place  on  Day  5,  but  the  northern  portion  of 
the  left  and  center  columns  were  problematic.  Data  packets  from  the  undersea  vehicle 
were  successfully  transmitted  to  the  ship  via  cellular  Nodes  19,  28,  43,  24,  24,  43,  43,  55, 
44,  and  43,  consecutively. 

6.  Day  Six 

Calmer  conditions  prevailed  on  Day  6.  Winds  were  approximately  10-20  kts  and 
seas  2  to  4  feet  with  swells  of  6  to  8  feet.  The  ship  was  moored  just  2  nautical  miles  from 
the  racom  buoys  and  maintained  continuous  FreeWave  connectivity  with  the  deployed 
gateways.  Network  rerouting  was  at  a  minimum  and  it  appeared  as  if  the  network  was  in 
working  order,  with  the  exception  of  the  center  column  on  the  300-meter  contour.  The 
entire  left  column  was  functional.  Node  55  also  appeared  to  be  in  working  order.  Data 
packets  from  the  undersea  vehicle  were  successfully  transmitted  to  the  ship  via  cellular 
Nodes  35,  35,  34,  34,  24,  21,  24,  26,  24,  20,  44  and  43,  consecutively. 

7.  Day  Seven 

The  weather  provided  calm  conditions  with  winds  from  10  to  15  kts  and  seas  of  2 
to  4  feet  with  swells  of  4  to  6  feet.  Only  two  minor  network  changes  were  made,  and  the 
center  column  of  nodes  still  exhibited  problems.  Although  the  undersea  vehicle  operated 
in  the  domain  of  the  Seaweb  grid  only  briefly  this  day,  data  packets  were  successfully 
transmitted  to  the  ship  via  cellular  Nodes  30,  28,  26,  22,  21,  and  24,  consecutively. 

8.  Day  Eight 

By  the  end  of  the  experiment,  the  deployed  Seaweb  grid  of  3  racom  buoys  and  40 
repeaters  were  fully  functional,  save  for  Nodes  23  and  25.  The  7  nodes  composing  the 
original  pilot  grid  (Seaweb  Nodes  11-17)  had  been  deployed  16  days  and  remained 
operational  with  good  battery  readings.  The  remaining  nodes  forming  the  rest  of  the 
operational  grid  had  been  deployed  15  days  with  good  battery  readings.  The  ship 
personnel  optimized  network  routing  and  verified  connectivity  with  the  deployed 
modems  in  the  grid.  The  successful  rerouting  of  the  network  shows  the  feasibility  and 
importance  of  future  Seaweb  networks  to  heal  routing  following  the  loss  or  addition  of 
nodes.  On  Day  8  data  packets  from  the  undersea  vehicle  were  successfully  transmitted  to 
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the  ship  via  cellular  Nodes  24,  21,  21,  19,  19,  21,  22,  26,  28,  30,  34,  32,  30,  26,  26,  44, 
19,  19,  24,  28,  29,  27,  55,  22,  32,  32,  and  32,  consecutively. 

9.  Day  Nine 

Interestingly,  at  the  end  of  the  experiment,  the  network  routing  was  at  its  most 
optimal.  Unfortunately  the  undersea  vehicle  did  not  transmit  data  packets  during  Day  9  of 
operations  because  it  was  operating  elsewhere.  After  recovery  of  the  grid  and  finding 
concrete  evidence  of  trawling  along  the  center  column,  it  is  obvious  that  had  the  network 
incorporated  the  center  column  as  leaf  nodes,  the  trawling  would  have  had  less  of  an 
impact  and  less  rerouting  would  have  occurred.  However,  the  process  followed  by  the 
remote  administrator  to  reach  this  state  of  functionality  is  highly  instructional  and  led  to 
identification  of  several  new  commands  that  were  implemented  post-experiment.  It  is 
also  justification  for  the  training  of  additional  operators  for  future  experimentation. 


C.  RECOVERY 

After  the  final  day  of  testing,  the  second  ship  progressively  recovered  the  Seaweb 
network.  Utilizing  the  GPS  locations  of  all  node  deployment  locations,  the  second  ship 
transited  the  grid  and  utilized  a  deck-box  to  actuate  the  acoustic  release  for  recovery. 
Upon  recovery,  it  became  even  more  evident  that  the  grid  had  been  severely  impacted  by 
trawling.  Figure  21  shows  the  network  as  routed  by  the  Seaweb  administrator  in  the  final 
day  of  experimentation,  Day  9,  alongside  the  actual  grid  that  was  recovered.  The 
deviations  and  casualties  are  significant  and  suggest  that  with  added  diagnostic  features, 
Seaweb  would  be  able  to  self-heal  and  overcome  quite  significant  damage. 

The  following  32  repeaters  were  successfully  recovered:  11,  12,  13,  14,  15,  16, 
17,  18,  19,  20,  22,  24,  26,  28,  29,  30,  32,  34,  36,  38,  39,  40,  41,  42,  43,  44,  46,  47,  48,  and 
49.  This  80%  recovery  rate  is  notable  in  that  it  was  achieved  without  support  from  a 
RHIB,  in  a  strong  current,  and  with  several  nodes  deployed  deeper  than  the  specified 
operating  depth  of  the  acoustic  releases.  Node  29  was  not  found  in  its  original 
deployment  position.  It  was  successfully  recovered  at  a  location  2.5  km  away  from  its 
deployment  station.  This  dislocation  is  thought  to  have  occurred  due  to  trawlers  working 
the  area.  Furthermore,  it  is  suspected  that  most  of  the  unrecoverable  nodes  were  damaged 
by  the  bottom  trawling. 
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Even  with  the  daily  reconstruction  of  the  network  routes,  it  is  difficult  to  pinpoint 
on  which  day  and  at  what  time  the  trawling  took  place.  We  know  that  two  trawlers  were 
operating  within  the  area  of  the  Seaweb  grid  throughout  recovery  operations,  Days  11-13. 
The  second  ship  had  previously  observed  two  similar  trawlers  in  the  same  area  on  Day  3 
of  experimentation  during  the  deployment  of  Node  55.  Seven  of  the  eight  unrecoverable 
nodes  and  the  one  dislocated  node  were  all  from  the  center  column  of  the  grid.  This 
indicated  that  trawling  was  concentrated  along  the  300-meter  contour.  This  is  the  same 
area  in  which  the  trawler  sightings  occurred.  Failure  modes  associated  with  the  dislocated 
and  unrecoverable  nodes  were  also  consistent  with  contact  by  trawls.  With  all  of  the 
evidence,  it  appears  the  major  trawling  impact  occurred  on  or  before  Day  2. 

No  traces  of  Nodes  23  or  25  were  found,  despite  ping  attempts  throughout  the 
entire  grid  area.  All  3  independent  acoustic  systems  (telesonar  modem  and  the  pair  of 
acoustic  releases)  did  not  respond.  These  nodes  were  problematic  from  the  beginning  of 
the  exercise  and  are  presumed  to  have  been  trawled  in  the  days  immediately  following 
deployment. 

Node  27  was  found  2.0  km  35 IT  away  from  its  deployment  station.  The  node  was 
located  through  ranging  and  trilateration  from  neighboring  nodes  using  Seaweb 
navigation  functions.  Although  all  3  acoustic  systems  were  responsive,  ranging  by  the 
deck  box  revealed  the  location  of  the  releases  were  300  meters  away  from  the  telesonar 
modem,  indicating  the  release  had  separated  from  the  modem.  Failure  of  the  float  to 
surface  following  successive  bum  commands  to  both  acoustic  releases  indicates  the  float 
had  been  severed. 

Node  29  was  successfully  recovered,  although  it  was  found  2.5  km  349T  away 
from  its  deployment  station.  The  telesonar  modem  was  undamaged  but  showed  traces  of 
red  and  green  paint.  This  telesonar  modem  carried  sediment  indicative  of  being  dragged 
along  the  bottom. 

Node  31  was  found  2.2  km  262T  away  from  its  deployment  station.  All  3  acoustic 
systems  were  responsive;  therefore  failure  of  the  node  to  surface  following  burn 
commands  to  both  acoustic  releases  indicates  the  float  had  been  severed.  This  node  was 


38 


found  to  be  collocated  with  Node  33,  suggesting  these  nodes  had  perhaps  been  hauled  up, 
floats  severed,  and  the  modems  and  releases  discarded  overboard. 

Node  33  was  found  4.7  km  18 IT  away  from  its  deployment  station.  All  3  acoustic 
systems  were  responsive.  It  is  thought  that  the  sub-surface  float  was  severed  from  this 
node  as  well. 

Node  35  was  found  at  its  deployment  station,  however  it  did  not  surface.  Loss  of 
the  float  would  have  caused  the  modem  to  rest  on  the  seafloor  and  possibly  bury  in  the 
sediment.  A  collapsed  posture  is  consistent  with  the  poor  acoustic  performance  of  this 
node  during  the  experiment.  Node  37  was  also  found  at  its  deployment  station,  but  did 
not  surface. 

Node  45  did  not  respond  through  either  the  telesonar  modem  or  acoustic  releases. 
This  is  the  only  unrecovered  node  not  belonging  to  the  center  column.  Therefore,  its 
failure  is  not  necessarily  attributable  to  trawling.  This  node  was  in  water  deeper  than  the 
300-m  rating  of  the  acoustic  releases,  but  there  is  no  direct  evidence  to  indicate  failure  of 
the  releases. 
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Figure  21. 


The  network  routing  on  the  last  day  of  the  experiment,  Day  9,  is  shown  on 
the  left  above  in  comparison  to  that  which  was  recovered  post-experiment,  Days 
10-1 1,  on  the  right.  The  network  was  severely  impacted  by  trawlers.  The  trawlers 
were  seen  within  the  area  on  three  different  occasions.  Performance  was  greatly 
impacted  by  this  major  disruption,  but  reliable  800  bits/s  communications  were 
still  maintained. 
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VII.  SEAWEB  2004  PERFORMANCE 


Seaweb  quality  of  service  is  limited  by  low-bandwidth,  half-duplex,  and  high- 
latency  telesonar  links.  Poor  propagation  conditions  and  elevated  noise  levels  contribute 
to  occasional  network  outages  and  corrupted  data  packets  [9],  Seaweb  2004  performance 
is  quantified  by  the  overall  message  throughput,  latency  of  network  packets,  and  the 
contributing  factors  for  the  dropped  messages. 


A.  MESSAGING  SUCCESS 

Throughput  is  defined  as  the  amount  of  information  transmitted  through  a 
communications  link.  Factors  such  as  bandwidth,  errors,  congestion,  and  the  transmission 
medium  properties  affect  the  total  throughput  values.  For  this  analysis  we  discuss 
throughput  in  terms  of  overall  messaging  success  at  the  transport  layer,  i.e.,  the  total 
number  of  network  packets  successfully  transmitted  through  the  network  and  received 
error-free  at  the  destination  node. 

Several  types  of  messages  were  sent  over  the  course  of  the  Seaweb  2004 
experiment.  Examples  of  the  kinds  of  messages  were  own  vehicle  positions,  command 
and  control  messages,  general  network  health  monitoring,  node-to-node  ranging,  and 
network  routing.  Regardless  of  type,  each  data  packet  sent  through  the  Seaweb  server  is 
designated  with  a  network  packet  sequence  number  and  a  timestamp.  The  sequence 
numbers  range  from  1  to  255,  and  then  cycle  back  to  1.  By  tracking  the  sequence  number 
along  with  the  associated  timestamp,  we  are  able  to  count  the  number  of  packets 
successfully  transmitted  and  received  by  the  ship  and  by  the  undersea  vehicle.  Limiting 
our  analysis  to  traffic  between  the  undersea  vehicle  and  the  ship,  the  messaging  success  is 
compiled  in  Figure  22. 

Initially  the  Seaweb  administrator  exercised  the  Seaweb  pilot  network  through  a 
FreeWave  radio  link  between  the  ship  and  the  deployed  racom  buoy.  All  7  pilot  grid 
repeater  nodes  were  found  to  be  fully  functional.  The  testing  performed  included  data 
telemetry  of  1 -kilobyte  test  packets  at  information  bit-rates  of  300  and  800  bits/s.  Testing 
also  involved  remote  selection  of  transmit  power  levels,  node-to-node  acoustic  ranging, 
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node-to-multinode  ranging,  and  networked  interrogation  of  modem  diagnostics.  As  a 
result  of  those  tests,  the  baseline  data  rate  for  Seaweb  2004  was  increased  from  300  bits/s 
to  800  bits/s,  and  the  baseline  transmit  power  level  was  set  to  6  dB  less  than  the 
maximum  power  available.  Successful  communications  with  these  parameters  at  ranges 
exceeding  6  km  provided  confidence  that  the  3 -km  node  spacing  would  reliably  serve  the 
needs  of  the  exercise.  The  overall  results  support  this  conclusion  as  well. 
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Figure  22.  The  total  amount  of  messages  sent  from  the  undersea  vehicle  and  the  ship 

as  well  as  those  received  onboard  the  undersea  vehicle  and  ship.  One  hundred  and 
sixty  messages  were  unsuccessfully  received  onboard  the  ship  and  fifty  messages 
were  not  received  onboard  the  undersea  vehicle.  Section  C  identifies  the  reasons 
for  these  dropped  messages. 
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Figure  23. 


Figure  24. 


Transport  Layer  Messaging  Success 
Undersea  Vehicle  to  Ship 


Messaging  success  from  undersea  vehicle  to  ship  also  tended  to  increase 
on  a  daily  basis.  As  the  experiment  progressed,  sensitivity  to  the  issues  of 
proximity  and  aspect  of  the  undersea  vehicle  relative  to  the  cellular  node 
increased  messaging  success. 


Transport  Layer  Messaging  Success 
Ship  to  Undersea  Vehicle 


Messaging  success  from  ship  to  undersea  vehicle  increased  over  the 
course  of  the  experiment.  This  is  attributed  to  decreasing  ambient  noise  levels 
within  the  environment,  troubleshooting  and  rerouting  of  the  network,  and 
increased  operator  proficiency. 
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During  the  days  of  experimentation,  the  Seaweb  administrator  did  not  exercise  the 
grid  in  a  rigorous  manner.  As  the  goal  of  the  experiment  was  bidirectional 
communications  between  the  undersea  vehicle  and  the  ship  and  the  communications 
protocol  established  that  the  surface  vehicle  would  wait  to  receive  a  message  prior  to 
sending  one,  the  operators  were  compelled  to  keep  the  network  available  to  the  undersea 
vehicle.  Network  packets  were  sent  to  various  nodes  within  the  grid  only  in  response  to 
an  issue  encountered  with  that  node  or  one  around  it,  or  during  time  periods  when  the 
undersea  vehicle  was  known  to  be  operating  elsewhere. 

Daily  transport  layer  success  rates  to  ship  and  undersea  vehicle  are  compiled  in 
Figures  23  and  24,  respectively.  The  trend  shows  steadily  improving  performance  over 
the  course  of  the  experiment,  especially  for  communications  to  the  undersea  vehicle. 
Progressively  increased  messaging  success  to  the  undersea  vehicle  is  attributable  to  the 
following  factors.  The  established  communications  protocol  favored  the  messaging  from 
the  ship  to  the  undersea  vehicle.  The  ship  knew  from  which  cell  the  undersea  vehicle 
transmitted  and  used  this  information  to  return  a  response  message  prior  to  the  undersea 
vehicle  leaving  that  cellular  area  of  the  grid.  As  the  undersea  vehicle  maneuvered  within 
the  domain  of  the  grid,  the  ship  was  able  to  observe  behavior  and  improve  performance 
of  the  various  nodes  in  the  grid.  These  optimizations,  of  course,  should  have  occurred 
prior  to  the  experiment  with  end-to-end  testing  as  had  been  planned.  As  well,  the  ambient 
noise  within  the  operating  environment  decreased  during  the  experiment,  as  supported  by 
Figure  6. 

Not  only  did  the  testing  and  correcting  by  the  Seaweb  administrator  increase 
messaging  success  to  the  undersea  vehicle,  it  also  increased  messaging  success  from  the 
undersea  vehicle  as  well.  After  discovering  the  loss  of  Nodes  23  and  25,  the  ship  was  able 
to  reroute  network  traffic  around  that  area,  thus  significantly  improving  the  overall 
performance  of  the  grid.  The  undersea  vehicle  also  did  not  exercise  the  grid  uniformly.  It 
tended  to  use  the  southernmost  portion  of  the  grid  more  than  the  northern  portion.  Due  to 
the  nonsystematic  fashion  in  which  nodes  were  selected  as  communication  access  points, 
it  is  difficult  to  determine  the  relative  effectiveness  of  all  network  nodes. 
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B.  LATENCY 


The  automatically  generated  timestamps  in  the  Seaweb  server  archive  were  used 
to  calculate  latency  times.  The  latency  times  are  divided  into  3  analysis  categories:  ship 
to  undersea  vehicle,  undersea  vehicle  to  ship,  and  ship  to  fixed  node.  Latencies  are  then 
plotted  as  a  function  of  range.  Ranges  are  calculated  by  using  the  distance  from  the 
gateway  buoy  to  the  network  node  as  addressed  by  the  administrator  or  as  used  as  a 
communications  access  point  by  the  undersea  vehicle.  As  expected,  latency  increased 
linearly  with  range.  In  order  to  support  effective  bidirectional  communications,  it  is 
imperative  that  latency  times,  much  larger  than  terrestrial  counterpart  systems,  be  kept  to 
a  minimum.  Latency  times  will  decrease  with  the  planned  implementation  of  automatic 
“best-route”  routing  algorithms  in  the  future. 


Surface  Ship  to  Undersea  Vehicle  Latency 


Range  (nm) 


♦  Surface  Ship  to  Undersea 
Vehicle 

Linear  Fit 


Figure  25.  The  ship  to  undersea  vehicle  latency  is  calculated  using  the  timestamps 

entered  into  the  database  archives  by  the  Seaweb  servers.  This  is  a  latency  that 
includes  the  handshaking  process  between  all  nodes  in  the  route  from  source  to 
destination. 
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Undersea  Vehicle  to  Surface  Ship  Latency 


Figure  26. 


Figure  27. 


♦  Undersea  Vehicle  to  Surface 
Ship  Latency 

Linear  Fit 


Range  (nm) 


The  undersea  vehicle  to  ship  latency  is  calculated  using  the  timestamps 
from  the  database.  The  range  is  determined  by  using  the  distance  from  the  cellular 
node  the  undersea  vehicle  used  to  transmit  the  data  packet  to  the  ship  and  back. 
The  distance  from  the  undersea  vehicle  to  the  node  is  neglected. 


Message  Latency  from  Surface  Ship  to  Nodes 


♦  RV1  to  Nodes 
- Linear  (RV1  to  Nodes) 


Range  (nm) 


Nodal  latencies  are  calculated  in  the  same  fashion  as  those  of  the  ship  and 
undersea  vehicle.  These  transmissions  were  always  between  fixed  locations  which 
explain  is  why  they  exhibit  a  more  linear  fit. 
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C.  DROPPED  MESSAGES 

A  dropped  message  is  defined  as  a  message  that  was  transmitted  by  a  source  node 
and  not  received  by  the  intended  destination  node.  Some  of  these  dropped  messages  are 
the  result  of  human  interaction  with  the  system,  while  most  are  due  to  various 
engineering  issues  associated  with  the  present  Seaweb  system  operating  with  a  mobile 
node.  The  sequence  number  and  specific  timestamp  enable  us  to  track  each  network 
packet  from  source  to  destination.  A  sequence  number  that  is  not  correctly  received  is 
analyzed  and  the  dropped  message  is  attributed  to  one  of  many  causes  based  on  the 
logged  link  diagnostics. 

In  this  analysis,  transmissions  are  separated  into  those  transmitted  by  the  undersea 
vehicle  and  those  transmitted  from  the  ship.  These  data  are  compiled  and  charted  in 
Figures  28  and  29,  with  a  view  of  overall  performance  at  the  transport  layer.  The 
undersea  vehicle  sent  considerably  more  network  packets  as  a  result  of  the  established 
Seaweb  2004  session  protocol.  The  following  is  a  discussion  of  the  categories  of  dropped 
messages  identified  during  Seaweb  2004. 

Several  messages  were  dropped  because  of  link  impairments.  These  categories 
include  link  unavailability  (RTS  timeout),  low  signal-to-noise  ratio  (SNR),  and  data 
failure  problems.  For  this  analysis,  the  low-SNR  category  captures  most  physical-layer 
degradations  caused  by  the  combination  of  low  signal  (i.e.,  poor  propagation)  and  high 
noise. 

Request-to-Send  timeouts  occur  when  Node  A  initiates  the  link-layer  handshaking 
procedure  with  Node  B,  but  Node  A  does  not  receive  a  Clear-to-Send  message.  When 
this  happens,  Node  A  will  continue  to  send  9-byte  RTS  packets  up  to  a  preset  number  of 
attempts  programmed  by  the  administrator.  Upon  time-out,  the  packet  is  dropped. 

Even  when  the  RTS/CTS  handshake  is  successful,  low-SNR  errors  occur  when 
the  link  budget  is  not  adequate  for  error-free  reception  of  the  data  packet.  If  Node  B 
cannot  demodulate  the  data  packet  correctly,  it  produces  a  low-SNR  detection  error  and 
drops  the  network  packet. 
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Transport  Layer  Error  Modes  for 
Undersea  Vehicle  to  Ship  Message  Attempts 


Figure  28. 


Figure  29. 
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The  160  dropped  messages  not  received  successfully  by  the  ship  are 
attributed  to  the  various  factors  listed  in  this  chart. 


Tranport  Layer  Error  Modes  for 
Ship  to  Undersea  Vehicle  Message  Attempts 


MODEM  REBOOT, 
1 

NO  XMT,  2 


ERROR  FREE,  61 


The  50  dropped  messages  not  received  successfully  by  the  undersea 
vehicle  are  attributed  to  the  various  factors  listed  in  this  chart. 
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Data  Failure  error  messages  cause  packets  to  be  dropped  when  Node  B  receives 
the  data  packet,  assumes  it  was  correctly  transmitted,  and  upon  demodulation  realizes  the 
data  string  is  corrupt.  Normally  in  the  hand-shaking  procedure  Node  B  would  send  a 
Selective  ARQ  message  to  Node  A  upon  receipt  of  the  corrupt  packet.  If  Node  A  does 
not  receive  the  SRQ  within  the  allotted  time  period,  it  does  not  resend  the  data  packet, 
thus  producing  a  dropped  message. 

Hardware  issues  caused  dropped  messages  when  the  racom  buoy  had  to  be 
rebooted  and  when  no  transmit  (No  XMT)  errors  occurred.  If  a  network  packet  was  in  the 
process  of  being  transmitted,  the  reboot  would  cause  the  packet  to  be  dropped  since  it 
never  made  it  from  the  ship  to  the  racom  gateway  buoy  and  henceforth  to  the  addressed 
node  or  undersea  vehicle. 

Transmissions  originating  at  the  undersea  vehicle  were  more  prone  to  being 
dropped  since  the  vehicle  often  did  not  have  a  good  sense  of  where  it  was  relative  to  the 
nodes  in  the  grid.  Physical  limitations  such  as  distance  from  the  node  used  as  the 
communications  access  point,  vehicle  aspect  to  the  node,  a  bad  link  between  other  nodes 
within  the  grid  that  are  being  used  to  transmit  through  to  the  destination,  and  other  sonars 
operating  within  the  water-space  around  the  network  caused  messages  to  be  dropped. 
Because  Seaweb  is  currently  operated  with  man  in-the-loop,  operator  error  sometimes 
adversely  influenced  messaging  success. 

Overall,  most  of  the  issues  influencing  Seaweb  2004  message  delivery  can  be 
resolved  by  improving  the  engineering  of  the  system  with  mechanisms  such  as  link 
automatic  rerouting  and  modem  reboots.  Others,  such  as  operator  error  and  other  sensors 
operating  within  the  same  water-space,  need  continued  testing  and  development. 


49 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


50 


VIII.  FUTURE  IMPROVEMENTS 


The  5  by  20  nautical  mile  Seaweb  2004  grid  of  40  subsea  nodes  was  the  largest 
wide-area  acoustic  network  ever  to  be  demonstrated.  As  with  any  experimental 
implementation,  there  is  room  for  improvement  with  equipment,  hardware,  and 
personnel.  Recommendations  follow. 

A.  NAVIGATION  POSSIBILITIES  WITHIN  THE  SEAWEB  GRID 

A  significant  lesson  learned  is  the  importance  of  the  undersea  vehicle  awareness 
of  its  own  position  within  the  grid  as  a  prerequisite  for  effective  operation  as  a  mobile 
node.  This  lesson  has  led  to  the  dual  use  of  the  Seaweb  fixed  grid  as  an  undersea 
constellation  of  reference  points  for  GPS-like  navigation.  A  series  of  3  Seaweb 
engineering  experiments  in  2005  (May,  July,  December)  are  developing  that  navigation 
capability  as  a  Seaweb  function.  Seaweb  navigation  and  Seaweb  communication  are 
therefore  becoming  highly  interdependent  functions,  especially  so  for  future  mobile 
connectivity  requirements.  [24,  25] 

B.  MOBILE  CONNECTIVITY 

Implementing  mobile  connectivity  will  enable  seamless  communications  with 
undersea  vehicles  in  the  Seaweb  domain.  In  order  to  achieve  this,  cellular  addressing 
needs  further  development  to  support  automated  mobile  connectivity.  Seaweb  diagnostics 
must  be  improved  and  further  automated.  Finally,  a  true  ping  command  that  would  trace 
the  outbound  and  inbound  routes  would  aid  in  post-experiment  exercise  analysis. 

C.  ROUTING 

Network  routing  and  initialization  was  done  manually  during  this  experiment. 
Seaweb  of  tomorrow  is  an  ad  hoc  network  which  will  autonomously  establish  preliminary 
connections.  A  procedure  is  required  for  performing  initialization  and  maintaining 
connectivity  to  all  nodes  within  acoustic  range.  During  the  initialization  process,  the 
nodes  would  create  their  own  neighbor  tables  to  include  the  quality  of  the  acoustic  links 
between  themselves  and  their  neighbors.  A  master  node  would  collect  this  information  to 
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determine  the  best  routing  configuration.  By  utilizing  an  adaptive  routing  algorithm,  an 
increase  in  robustness  would  allow  the  network  to  react  to  changing  channel  conditions 
without  interruption  in  communications.  Each  time  the  network  is  used,  the  link 
parameters  exercised  along  the  route  would  be  reported,  thus  allowing  the  master  node  to 
efficiently  monitor  network  health  [16,  18]. 

Neighbor  Sense  Multiple  Access  (NSMA)  is  a  network  layer  process  that 
passively  monitors  Seaweb  traffic.  After  assessing  the  communications  status  of  neighbor 
nodes,  a  node  with  a  message  to  be  transmitted  avoids  unnecessary  collisions  by  delaying 
new  dialog  until  the  neighbor  node  is  finished,  or  it  transmits.  This  is  an  added  measure 
for  collision  avoidance.  NSMA  was  successfully  demonstrated  at  sea  in  a  February  2005 
Seaweb  experiment  [16]. 

In  future  experiments,  routine  testing  of  all  routes  within  the  network  should  take 
place  on  a  daily  basis.  This  would  provide  a  baseline  from  which  network  reconstruction 
could  be  derived.  Without  daily  verification  of  the  network  health,  it  is  difficult  to  specify 
the  time-frame  in  which  a  node  stopped  working  and/or  was  trawled. 

D.  RACOM  BUOYS 

In  order  to  implement  Seaweb  as  a  fixture  for  underwater  communications,  it  is 
imperative  that  an  improved  design  for  racom  buoy  rugged  handling  be  designed.  Until 
then,  waiting  for  calm  seas  is  necessary  for  successful  recovery.  The  radar  reflector 
should  be  eliminated,  a  taller  prow  designed,  flush  GPS  and  Iridium  antennas  added,  and 
an  improved  transducer  cable  developed.  Racom  buoy  wet-end  survivability  must  be 
addressed  as  well.  Utilizing  the  military  version  of  the  FreeWave  radio  modems 
operating  at  138  MHz  and  supporting  up  to  50-nautical-mile  line-of-sight  connectivity 
vice  the  shorter  range  900-MHz  commercial  FreeWave  modems  would  increase  stable 
connectivity  for  communications.  In  addition,  efforts  are  underway  to  produce  an  energy¬ 
harvesting,  mooringless  racom  buoy  capable  of  maintaining  station  or  vectoring  to  a  new 
station  upon  command.  [3] 
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E.  TELESONAR  NODES 

Seaweb  capability  is  migrating  to  new  telesonar  modem  hardware  compatible 
with  A-sized  air-deployable  packaging  and  with  submarine  signal-ejector  packaging 
enabling  further  versatility  and  military  applicability.  The  Seaweb  of  tomorrow  will 
operate  in  multiple  acoustic  bands  and  will  incorporate  electronically  steered  directional 
transducers  for  improved  transmission  security  (TRANSEC),  link  budget,  energy 
conservation,  and  multiple-access  performance.  The  new  modems  will  incorporate 
channel-adaptive  modulation,  spread-spectrum-modulated  utility  packets,  power  control, 
and  coherent  detection. 

F.  SEAWEB  ADMINISTRATORS,  OPERATORS,  AND  USERS 

As  with  any  system,  it  is  imperative  that  there  be  enough  personnel  trained  to 
operate  and  facilitate  use  so  that  the  system  can  physically  be  manned  in  an  intelligent 
and  sophisticated  manner.  With  the  lack  of  personnel  qualified  to  manipulate  the  system, 
the  individuals  that  were  trained  to  administer  the  server  became  fatigued.  In  order  to 
exploit  Seaweb  capabilities  more  operators  need  to  be  trained  and  made  available  during 
testing  periods.  Since  future  testing  will  involve  more  manned  platforms,  it  is  all  the  more 
important  to  recruit  and  train  new  Seaweb  personnel. 

It  is  also  recommended  that  a  shipboard  sonobuoy  receiver  system  be  procured  for 
independent  real-time  monitoring  of  Seaweb  acoustic  activity  and  ambient  noise. 

G.  FINANCIAL  SUPPORT  FOR  FUTURE  ASW  CAPABILITIES 

The  Seaweb  underwater  acoustic  wide-area  network  shows  great  potential.  It  is 
consistent  with  the  future  proliferation  of  autonomous  undersea  sensors  and  vehicles.  Not 
only  does  Seaweb  show  potential  for  communication  and  navigation  of  an  undersea 
vehicle,  but  it  could  conceivably  be  incorporated  as  a  rapidly  deployable  undersea 
wireless  grid  supporting  communication  and  navigation  (comm/nav)  for  a  patrolling  SSN 
operating  at  speed  and  depth.  Seaweb  demonstrated  timely  communications  to  and  from 
the  Seaweb  2004  undersea  vehicle.  In  the  current  anti-submarine  warfare  (ASW) 
environment,  Seaweb  could  act  as  the  bridge  between  terrestrial  communications  and  the 
underwater  battlespace.  It  could  potentially  afford  submarines  the  ability  to  communicate 
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in  stride  without  surfacing.  In  order  for  this  to  come  to  fruition,  the  Navy  needs  to  invest 
resources  in  the  procurement  and  further  development  of  Seaweb  capabilities.  Seaweb 
enables  new  concepts  of  operations  involving  autonomous  distributed  systems,  and  it 
integrates  existing  systems  into  that  future  architecture. 


54 


IX.  CONCLUSIONS 


The  Seaweb  architecture  anticipates  the  inevitable  proliferation  of  future  undersea 
sensors.  Seaweb  is  a  technology  motivated  by  the  need  to  network  these  distributed 
sensors  and  communicate  with  them  through  gateway  nodes.  It  is  a  malleable  architecture 
that  can  be  matched  to  the  characteristics  of  the  particular  ocean  environmental 
conditions  and  mission  at  task. 

The  Seaweb  2004  experiment  demonstrated  a  5  by  20  nautical  mile  grid,  the 
largest  undersea  network  to  date.  The  network  maintained  a  reliable  800  bits/s  physical 
layer  while  demonstrating  effective  collision  tolerance.  As  well,  rerouting  healed  the 
network  following  severe  impact  by  trawling  within  the  first  few  days  of  testing.  During 
the  experiment  less  than  25%  of  the  overall  telesonar  node  battery  capacity  was 
consumed.  The  undersea  vehicle,  while  a  disadvantaged  receiver,  maintained 
bidirectional  communications  through  the  low-power  distributed  grid. 

The  overall  performance  of  Seaweb  2004  was  impacted  by  the  use  of  an 
azimuthally  sensitive  undersea  vehicle,  no  opportunities  for  end-to-end  testing  prior  to 
commencing  the  exercise,  adverse  weather  conditions,  trawling  impact,  and  limited 
operator  availability.  Even  with  the  very  short  schedule  and  many  challenges,  Seaweb 
2004  has  successfully  demonstrated  an  effective  network  architecture  for  undersea 
vehicle  communications  at  speed  and  depth.  Seaweb  is  scaleable,  and  it  is  consistent  with 
future  operations  involving  deployable  autonomous  sensors  and  unmanned  undersea 
vehicles  as  force  multipliers.  The  current  operational  environment  requires  that  offboard 
sensors,  fixed  and  mobile,  be  developed  and  ready  for  fleet  use  within  the  next  few  years. 
Seaweb  stands  as  the  most  developed  underwater  acoustic  communications  network  and 
is  a  new  ASW  capability  deserving  Navy  investment. 
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